Τα φωτα σας για build server.

[timcook]

Θα χρειαστεί να επεξεργαστώ εκατομμύρια (~1GB) μικρά αρχεία (<1KB) πολλες φορές (20-30) σε όσο χαμηλότερο χρονικό διάστημα γίνεται.

Εικονικό setup:

NVMe: Samsung 970 Pro 2TB

Folder: "C:\Server"

C:\Server\00000000000000.txt (285 bytes)

C:\Server\00000000000001.txt (486 bytes)

...

C:\Server\00007833429483.txt (340 bytes)

Ο φάκελος περιέχει τρισεκατομμύρια (1.73TB) μικρά αρχεία (<1KB).

Στο πρώτο step πρέπει να διαβάσω 200MB (δηλαδή ~200,000 τέτοια μικρά αρχεία) και να γράψω 1MB, στο τρίτο να διαβάσω 1GB και να γράψω 5MB, στο τρίτο να διαβάσω 13GB και να γράψω 240MB, ...

1 compute cycle μπορεί να έχει 10 τέτοια steps.

2-3 compute cycles χρειάζονται για να λύσουν ένα query.

Με τι hardware μπορώ να ελαχιστοποιήσω τον χρόνο που χρειάζεται για να λύσω ενα query?

Σκέφτηκα οτι παίζουν ρόλο οι τάχυτητες των NVMe και RAM:

• R3 2200G
• G.Skill Ripjaws 2x8GB DDR4-3000Mhz
• 2 x Samsung Evo 970 2TB NVMe (RAID 0)
• Asrock DeskMini A300

Θα χρησιμοποιήσω το μηχάνημα σαν server.

Π.χ. αν 1 compute cycle μου παίρνει συνολικά 24.4GB (~25,000,000 μικρά αρχεία) σε read και 0.4GB σε write ενώ οι NVMe φτάνουν σε 5GB/s σε RAID 0 μπορώ να υπολογίσω οτι θα λυθει σε ~5sec?

Μήπως πρέπει να το λύσω στην RAM?

Επεξ/σία 6 Απριλίου 2019 από timcook

[tsofras]

Με τι τρόπο επεξεργαζεσαι τα αρχεία? Έχεις γράψει κάποιο πρόγραμμα? Τρέχει με πολλά. Threads ? Έχεις κάποια cache υλοποιημένη? 

Όλα αυτά μπορεί να βοηθήσουν να βρούμε το bottleneck και τι θα χρειαστείς από hardware 

[timcook]

22 λεπτά πριν, tsofras είπε

Με τι τρόπο επεξεργαζεσαι τα αρχεία? Έχεις γράψει κάποιο πρόγραμμα? Τρέχει με πολλά. Threads ? Έχεις κάποια cache υλοποιημένη? 

Όλα αυτά μπορεί να βοηθήσουν να βρούμε το bottleneck και τι θα χρειαστείς από hardware 

Κάθε ένα αρχείο είναι μια μεταβλητή π.χ. το 00003400350.txt έχει την δομή ενώς cell segment με συνδέσεις [000003043435, 00000650636, ...] για 2187 synapses κάθε μια με δικιά της δομή π.χ. το 00000045400654.txt είναι synapse και έχει μέσα [0000000394934, 0.34];[0000000034043,0.49];... που είναι συνδέσεις με connection ID και connection permanence για άλλα cell segments. Πρέπει να διαβάζω δισεκατομμύρια τέτοια αρχεία το δευτερολεπτο επειδή κάποιος που θα θέλει να το χρησιμοποιήσει δεν θα ήθελε να περιμένει λιγότερο απο 1sec για την απάντηση. Δεν παίζει να γίνει με NMVe, 128GB RAM το όριο.

Η ερώτηση μου είναι: αν ο σκληρός λεει οτι η ταχύτητα read είναι 3.5GB/s σημαίνει οτι μπορεί να διαβάσει 3.500.000x1KBfiles/s?

Επεξ/σία 6 Απριλίου 2019 από timcook

[asmilon]

Γιατι δεν φτιαξατε κατι που να δουλευει σε μια database αντι για τρισεκατομμυρια μικρα αρχεια; Μου φαινεται φοβερη σπαταλη πορων να χρειαζεται να ανοιγετε μεμονομενα txt αρχεια για να διαβαστουν και να γινει εγγραφη σε νεα αρχεια.

[Επισκέπτης]

Αν βάλεις κάτι δις αρχεία σε ένα folder το seek time θα είναι σε λεπτά, όχι σε δευτερόλεπτα. Πρέπει να τα φορτώσεις όλα σε μια database όπως σου πρότειναν γιατί αλλιώς δεν δουλεύετε αυτό το πράγμα έτσι όπως το περιγράφεις. Αν δεν μπορείς να κάνεις αυτό σπάστα τουλάχιστον σε directories όπου να έχεις το πολύ 10Μ αρχεία στο καθένα.

Eπίσης πρέπει να μας πεις το εκτιμώμενο TBW στο έτος. Πιθανόν να χρειαστεί να πας σε enterprise ssd κι όχι απλό consumer.

[timcook]

22 ώρες πριν, elorant είπε

Αν βάλεις κάτι δις αρχεία σε ένα folder το seek time θα είναι σε λεπτά, όχι σε δευτερόλεπτα.

Δεν ειχα ιδεα, ευχαριστω.

22 ώρες πριν, elorant είπε

Αν δεν μπορείς να κάνεις αυτό σπάστα τουλάχιστον σε directories όπου να έχεις το πολύ 10Μ αρχεία στο καθένα.

Μπορω να τα σπασω σε 6 directories.

Το μεγεθος καθε directory δεν ειναι ισο με το 1/6 του αρχικου μεγεθους.

Π.χ. Το πρωτο directory μπορει να ειναι 607MB σε μεγεθος και το τελευταιο 1.02TB.

Folder: "C:\Server\" 

C:\Server\Region1\ (607ΜΒ)

C:\Server\Region2\ (28GB)

...

C:\Server\Region6\ (1.02TB)

Σε ενα step σιγουρα θα χρειαστω αρχεια .txt μονο απο ενα συγκεκριμενο region αλλα η θεση των αρχειων που θα χρειαστω ειναι τελείως τυχαια.

Π.χ. Αν διαιρεσω το Region6.txt (1.02ΤΒ) σε 100 κομματια των 10.02GB ισως να χρειαστει να διαβασω τα 65 απ αυτα (~650GB) για να ολοκληρωθει ενα step.

Ειναι στατιστικα απιθανο να χρειαστω ολα τα αρχεια .txt απο 1 κομματι 10.02GB.

Ο μονος λογικα ορθος τροπος να διαιρεσεις το directory 1.02TB ειναι ειτε στις μικροτερες δυνατες διαιρεσεις (~300 byte) ειτε σε ενα μοναδιαιο αρχειο (1.02TB).

Εχω αυτο το build:

• R5 2600
• MSI B450I Gaming Pro AC
• Corsair Vengeance 2x8GB DDR4-3000Mhz
• Crucial MX500 500GB

Ας πουμε οτι αγοραζω εναν Samsung Evo 970 2TB (3.5GB/s) και τον γεμιζω με 6 αρχεία μεσα σε εναν φακελο "Server".

Folder: "D:\Server" (1.73TB)

D:\Server\Region1.txt (607MB)

D:\Server\Region2.txt (28GB)

D:\Server\Region3.txt (3GB)

D:\Server\Region4.txt (346GB)

D:\Server\Region5.txt (346GB)

D:\Server\Region6.txt (1.02TB)

Ολα τα .txt αρχεια ειναι η προσθεση των αρχειων .txt που θα υπηρχαν σε αυτο το region-directory.

Καθε αρχειο .txt είχε μεσα μια μεταβλητη (εναν αριθμο απο 0.0 μεχρι 1.0)

Δηλαδη, απ αυτο:

Folder: "D:\Server\Region1\" (607MB)

D:\Server\Region1\000000001.txt (content: "0.32")

D:\Server\Region1\000000002.txt (content: "0.54")

D:\Server\Region1\000000003.txt (content: "0.03")

...

D:\Server\Region1\000086403.txt (content: "0.48")

Σε αυτο:

File: "D:\Server\Region1.txt" (607MB)

000000001,0.32;

000000002,0.54;

000000003,0.03;

...

000086403,0.48;

Το αρχειο Region1.txt εχει connection IDs "00000000" μεγεθους 9 byte με connection permanence"0.00" 3 byte.

Συνολικα καθε συνδεση "000000000,0.00;" χρειαζεται 15 bytes αλλα ας πουμε μεσο οσο 100 bytes.

Το αρχειο Region1.txt εχει 607MB/ 100 bytes = 636,485,632 / 100 bytes = ~6 εκατομμυρια συνδεσεις.

Οταν το ανοιξω ο R5 2600 μπορει να το μεταφερει απ τον Evo 970 NVMe στην 2x8GB 3000Mhz RAM (σε <<1sec) και τελος το πανηγυρι.

Ετσι δουλευει το συστημα τωρα!

Το προβλημα ειναι οτι περιοριζομαι στο μεγιστο και ακριβο μεγεθος 128GB RAM.

Aν καθε συνδεση ειναι 100 bytes μπορω να επεξεργαστω το μεγιστο οσα 100 bytes connections χωραει η 128GB RAM.

Σε ρεαλιστικη λειτουργια, βγαλε 4GB για το λειτουργικο, μενουν 124GB.

124GB / 100 bytes = 133,143,986,176 / 100 bytes = ~1 δισεκατομμυρια συνδεσεις.

Οποτε ενα Region δεν μπορει να ειναι μεγαλυτερο απο ~1,000,000,000 συνδεσεις αν το κανω με την RAM.

Επελεξα να αλλαξω τον τροπο που δουλευει το συστημα.

Ενας 2TB NVMe θα μπορουσε να χωρεσει region με μεγεθος 2TB / 100 bytes = 21 δισεκατομμυριων συνδεσεων στα 471 ευρώ αντι 795 ευρώ (+μητρικη, επεξεργαστη, κτλπ).

Χρειαζομαι να μεταφερω στον NVMe το φορτο εργασιας για να αυξησω την χωρητικοτητα και να κτησω το υπολοιπο με βαση τα 3.5GB/s / 100 bytes αρχεια = 131 εκατομμυρια αρχεια ανα δευτερολεπτο.

ΕΡΩΤΗΣΗ

Αν ανοιξω ενα αρχειο με ονομα "D:\Server\Region6.txt" (1.73ΤΒ) πολυ μεγαλυτερο απ την διαθεσιμη RAM (12GB), απο εναν 2TB NVMe, μπορώ να διαβασω 131 εκατομμυρια τυχαια "100 bytes" ανα δευτερολεπτο?

22 ώρες πριν, asmilon είπε

Γιατι δεν φτιαξατε κατι που να δουλευει σε μια database αντι για τρισεκατομμυρια μικρα αρχεια; Μου φαινεται φοβερη σπαταλη πορων να χρειαζεται να ανοιγετε μεμονομενα txt αρχεια για να διαβαστουν και να γινει εγγραφη σε νεα αρχεια.

Με μια καλυτερη βαση δεδομενων νομιζω θα εχω παλι το ιδιο προβλημα hardware οπως θα ειχα αν τα εβαζα σε ενα αρχείο .txt

 

Επεξ/σία 8 Απριλίου 2019 από timcook

[Επισκέπτης]

Δεν μπορείς να διαβάσεις τυχαίες γραμμές σε ένα text αρχείο. Μόνο σειριακά μπορείς να το διαβάσεις. Ακόμα κι αν είχες 2TB RAM πάλι σειριακά θα το διάβαζε, απλά πιο γρήγορα. Γι αυτό σου προτάθηκε η λύση της database, ώστε να μπορείς να κάνεις indexing και να βρίσκεις οτιδήποτε θες πολύ πιο γρήγορα.

Update. Κάτι άλλο που παρατηρώ είναι ότι κρατάς πολλές περιττές πληροφορίες. Ποιος ο λόγος να αποθηκεύεις τα δεδομένα στη μορφή "000000003,0.03" και να μην το έχεις απλά ως "3,0.03". Γλυτώνεις ένα σωρό bytes. Για κάτι τρισεκατομμύρια εγγραφές μπορεί να γλυτώσεις το 70% του χώρου που σου τρώει τώρα.

Επεξ/σία 8 Απριλίου 2019 από Επισκέπτης

[timcook]

1 ώρα πριν, elorant είπε

Γι αυτό σου προτάθηκε η λύση της database, ώστε να μπορείς να κάνεις indexing και να βρίσκεις οτιδήποτε θες πολύ πιο γρήγορα.

Θα χρησιμοποιησω π.χ. MySQL για να φτιαξω εναν πινακα με δυο τιμες, connectionID και connectionPermanence,

Θα εχει τρισεκατομμυρια τετοια entries.

Ποσα μπορω να επεξεργαστω το δευτερολεπτο αν το ενα απ αυτα ειναι π.χ. 10 bytes σε 3.5GB/s NVMe?

Ποσο μειωνεται το 3.5GB/s?

Προφανως το αρχειο θα ειναι >1ΤΒ και η RAM 16GB.

Επεξ/σία 8 Απριλίου 2019 από timcook

[Επισκέπτης]

Ειλικρινά δεν έχω ιδέα. Θεωρητικά, εκατομμύρια. Αλλά εξαρτάται από το indexing, τι γλώσσα θα χρησιμοποιείς και την απόδοση της MySQL. Tables με τρισεκατομμύρια records είναι edge cases. Δεν έχω προσωπική εμπειρία από κάτι αντίστοιχο οπότε δεν γνωρίζω να σου πω με βεβαιότητα. Σε μια database που έχω στα 300 GB μπορώ και διαβάζω αρκετά εκατομμύρια records/δευτερόλεπτο με έναν SAS SSD. Αλλά ο πίνακας έχει διακόσια εκατομμύρια records, όχι τρις. Και βέβαια είναι πάνω σε ένα rig με δύο δωδεκαπύρηνους Xeon και 256GB RAM. Καμία σχέση με το hardware που περιγράφεις.

Επίσης εγώ δεν θα έπαιρνα NVMe δίσκο για κάτι τέτοιο γιατί χρειάζεσαι read intensive δίσκο. Οι consumer δίσκοι δεν κάνουν για τέτοια loads. Ρώτα καλύτερα στο subthread των δίσκων τι να πάρεις που έχουν πιο ειδικές γνώσεις. Με βάση αυτά που έγραψες στο αρχικό post έχεις 14GB read ανά βήμα και θες δέκα βήματα ανά compute cycle. Δηλαδή 140GB read. Kαι μετά θες 2-3 cycles ανά query. Δηλαδή minimum 300 GB reads/query. Πόσα queries θα τρέχεις ανά ημέρα;

[tmjuju]

Χμμμμ, Δεν πρέπει να είναι ο περιορισμός σου το max transfer rate που δηλώνουν οι δίσκοι
a. Περισσότερο είναι τα IOPS
Ο 970 EVO δεν είναι κακός αλλά μπορείς να βρεις και κάτι καλύτερο
Και το raid 0 είναι ένας καλός τρόπος να διπλασιάσεις τα IOPS
To raid 10, θα σου προσθέσει ασφάλεια (mirroring), και θα διατηρήσεις τα διπλά read IOPS, με τα μισά write του raid0 (αλλά δεν κάνεις πολλά writes)

b. Το άλλο μεγάλο overhead έρχεται από το ίδιο το filesystem (NTFS στην περίπτωση σου). Δεν είναι γρήγορο να ανοίξεις ένα αρχείο από τα δισεκατομμύρια που έχεις. Εάν χρονομετρήσεις, τσέκαρε το, μπορεί ο χρόνος να ανοίξεις το αρχείο να είναι μεγαλύτερος από το να το διαβάσεις.

Γενικά προσπαθείς να κανείς τα πάντα φθηνά από όσο βλέπω. Αλλά να ξέρεις ότι σε κάποιες περιπτώσεις θα σου ήταν χρήσιμο ένα σύστημα με περισσότερα PCIe lanes που να βλέπουν δίσκους. Σε κάποιες μητρικές οι nvme μοιράζονται τα ίδια lanes. Υπάρχουν και PCIe 8x κάρτες για να συνδέσεις δίσκους.
 

[timcook]

21 λεπτά πριν, tmjuju είπε

Χμμμμ, Δεν πρέπει να είναι ο περιορισμός σου το max transfer rate που δηλώνουν οι δίσκοι
a. Περισσότερο είναι τα IOPS
Ο 970 EVO δεν είναι κακός αλλά μπορείς να βρεις και κάτι καλύτερο
Και το raid 0 είναι ένας καλός τρόπος να διπλασιάσεις τα IOPS
To raid 10, θα σου προσθέσει ασφάλεια (mirroring), και θα διατηρήσεις τα διπλά read IOPS, με τα μισά write του raid0 (αλλά δεν κάνεις πολλά writes)

b. Το άλλο μεγάλο overhead έρχεται από το ίδιο το filesystem (NTFS στην περίπτωση σου). Δεν είναι γρήγορο να ανοίξεις ένα αρχείο από τα δισεκατομμύρια που έχεις. Εάν χρονομετρήσεις, τσέκαρε το, μπορεί ο χρόνος να ανοίξεις το αρχείο να είναι μεγαλύτερος από το να το διαβάσεις.

Γενικά προσπαθείς να κανείς τα πάντα φθηνά από όσο βλέπω. Αλλά να ξέρεις ότι σε κάποιες περιπτώσεις θα σου ήταν χρήσιμο ένα σύστημα με περισσότερα PCIe lanes που να βλέπουν δίσκους. Σε κάποιες μητρικές οι nvme μοιράζονται τα ίδια lanes. Υπάρχουν και PCIe 8x κάρτες για να συνδέσεις δίσκους.
 

Σωστα, προσπαθω να τα κανω ολα πιο φθηνα.

Αντι να φτιαξω καινουργιο συστημα (επεξεργαστη, μητρικη, κτλπ.) με 128GB RAM σκεφτομαι τροπους για να το κανω με εναν 2TB NVMe αυξανοντας και την μεγιστη χωρητικότητα.

Κοιταξα για Optane αλλα η αντιστοιχία ειναι σχεδον 1 ευρώ/1GB.

[Επισκέπτης]

Οι Optane είναι για συνδυασμό με μηχανικό δίσκο. Σε συνδυασμό με SSD δεν πρόκειται να δεις διαφορές. Και βέβαια δεν δουλεύουν μόνοι τους. Λειτουργούν ως cache.

[mechpanos]

Νομίζω ότι  πρέπει να ξεκινήσεις από το να βελτιστοποιήσεις την εφαρμογή σου.
Μετά μπορείς να περάσεις σε μια βάση δεδομένων που να μπορεί να χρησιμοποιεί πολλαπλά threads (νομίζω όλες οι μοντέρνες το μπορούν!) και αντίστοιχα να κάνεις την εφαρμογή να τα χρησιμοποιεί, ώστε πχ με έναν 1700 που έχει πέσει σε τιμή αλλά σηκώνει 16threads να κάνεις δουλειά πιο γρήγορα από το να φορτώσεις όλα τα αρχεία στην ram και να τα επεξεργάζεσαι ένα-ένα.

Χωρίς να ξέρω πώς να σε βοηθήσω περισσότερο, νομίζω ότι πρέπει να περάσεις πρώτα από το νήμα προγραμματισμού και μετά να επιστρέψεις για τελικές οδηγίες setup! Επένδυσε σε optimization της εφαρμογής που είναι τσάμπα!

[timcook]

34 λεπτά πριν, mechpanos είπε

Νομίζω ότι  πρέπει να ξεκινήσεις από το να βελτιστοποιήσεις την εφαρμογή σου.
Μετά μπορείς να περάσεις σε μια βάση δεδομένων που να μπορεί να χρησιμοποιεί πολλαπλά threads (νομίζω όλες οι μοντέρνες το μπορούν!) και αντίστοιχα να κάνεις την εφαρμογή να τα χρησιμοποιεί, ώστε πχ με έναν 1700 που έχει πέσει σε τιμή αλλά σηκώνει 16threads να κάνεις δουλειά πιο γρήγορα από το να φορτώσεις όλα τα αρχεία στην ram και να τα επεξεργάζεσαι ένα-ένα.

Χωρίς να ξέρω πώς να σε βοηθήσω περισσότερο, νομίζω ότι πρέπει να περάσεις πρώτα από το νήμα προγραμματισμού και μετά να επιστρέψεις για τελικές οδηγίες setup! Επένδυσε σε optimization της εφαρμογής που είναι τσάμπα!

To συστημα ειναι optimized, χρειαζομαι 100 retrievals/sec για εναν χρηστη. Αλλα αν το χρησιμοποιουν π.χ. 1,000,000 χρηστες με 100 retrievals το δευτερολεπτo παει στα 100,000 retrievals/sec (ας πουμε δεν θα κανουν retrievals το ιδιο second)

Επεξ/σία 8 Απριλίου 2019 από timcook

[mechpanos]

Καλά ρε Τιμολέοντα Μαγειρευτή, θα έχεις 1 εκ. χρήστες και ρωτάς στο Insomnia για build server...εννοώ μήπως το σκέφτεσαι too much?