sokkal erősebb gép (48mag, 64GBram), mégis majdnem 2x lassabb rajta a MongoDB

Sziasztok!

Egy sokkal erősebb gép közel 2x annyi idő alatt végzi el a MongoDB importálást, mint a jóval gyengébb és nem tudunk rájönni, hogy miért.

A teszteléshez ezt használtuk: https://github.com/jsteemann/BulkInsertBenchmark
Lokálisan futtatva: `php run.php`

Ami a stage szerveren 261,1 mp alatt lefut az a production-on csak 466,0 mp.
Vagy ami 9,2 alatt az 14,1 alatt.

A lekért MongoDB configból látszik, hogy a production szerveren a storageEngine {persistent} true-ra van állítva.
Azonban ha ezt módosítani akartuk az /etc/mongod.conf-ban (tudom YAML, tab nem lehet),
akkor 2-es kóddal elszáll a mongod main process, ami "The specified options are in error or are incompatible with other options."

Próbáltuk a loggolást teljesen kikapcsolni meg a diagnosztikai adatok gyűjtését, de az sem hozott eredményt.
Próbáltuk azt is, hogy mmapv1 helyett wiredTiger -re állítjuk a tárolást, de nem segített.

A production gép nem csinál ezen kívűl szinte semmit, mert nincs még publikálva az oldal.
Ha valakinek van bármi ötlete, hogy mit és hogyan próbáljunk ki, akkor kérjük írja meg.

A két gép configja:

1. production (fizikai gép)

2. stage (virtuális gép, KVM)

Hozzászólások

"Disk HDD"

Milyen HDD milyen RAID-ban?

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

Ennyi információ alapján még tippem sincs. Ugyanakkor azért megnézném, hogy a mongo hogyan fut az egyik és a másik gépen (cpu/mem/io használat egyebek) hátha abból látni valamit.
Gondolom meg van ennek is az oka, de miért nem ugyanolyan OS fut a kettőn?

FathoM

A procik tipusa es orajele? A prod gep mast is csinal olyankor? A stage kernelt is 4.4-re updateeljetek.

Ez nem a pontos CPU típus, az órajel mondjuk legalább kiderül. A stage gépen van egy 400MHz-es előny, bár ettől nem kéne kétszer gyorsabbnak lennie. Ami gyanús, hogy az első gépen ha sok NUMA node között ugrál a task ott viszont lehet veszteség.

Az a persistent=True az IN-MEMORY storage engint engedelyezi. Valoszinu hogy eleg sok adatot tol a memoriaba es kevesebb a disk I/O. Idovel aztan kiirja de gondolom a 64G-be eleg sok minden belefer es mongo egyebkent is szivesen elterpeszkedik es kihasznalja ami rendelkezesre all - plane ha kered is ra a konfigbol.

Shot in the dark, de amikor legutoljára ilyennel találkoztam (test rendszeren korrekt sebesség, éles rendszeren több nagyságrenddel lassabb, miközben a HW messze elég kellett volna, hogy legyen), egy haveged telepítés oldotta meg; gyakorlatilag állandóan üres volt az entropy pool és arra várt a rendszer.
Egy cat /proc/sys/kernel/random/entropy_avail -t megér.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ez pont akarmi lehet. A mongot nem ismerem de nem jo az eltero rendszer a dev es prod kozott de az itt egy update szerencse.

A verziok elterese mellett a numa lehet baj vagy, vagyis minden cpu var a masik altal kezelt memoriaraban levo adatra.

hdparm -tT ?
Iostat ?
Htop/stop valami piros?
Mekkora a db? Simán befér a kis gép memoriajaba is?

Esetleg ki lehetne próbálni, hogy ha 47 magot letiltasz, akkor gyorsabb lesz-e, vagy lasabb.

Az a nettó 60GiB az datastore-t tekintve nagyjából 70, ha raid1, akkor 140, ha meg replikálva van egy másik DC-be, akkor 280... És a SAN-okba való diszkek nem az olcsóságukról híresek, ráadásul ha jó iops-ot akarsz tengelyes diszkekkel, akkor sok, relative kisebb diszket pakolsz a motyó alá - ami sok fiók (az sem két fillér, bár a betolható diszkek kapacitását és árát tekintve nem vészes - kivéve, ha kevés üf. miatt kell polcokat venni...)
SSD-vel annyiban jobb a helyzet, hogy ott nem elég kevesebb meghajtó, és azt sem muszáj raid1 jelleggel összepakolni.

Egyszer elofordult, hogy brand gepen (ugy emlekzsem HP volt) a disk vezerlo ujabb firmware kb tizszeresere lassitotta a dolgokat. Firmware downgrade aztan megoldotta.
Szerintem nezzetek meg a firmwareket is a ketfajta gepen.

Ezek mégis milyen "gépek" ?! (közben jól értelmezem, ezek 4 socket -es gépek, egyenként 6 maggal) mármint a production gép... mert akkor az nem 48 mag, az csak 48 szál - HT ráadásul ezek eléggé öreg CPU -k

Sokat segitene kideriteni a problema okat, ha futna a sar a gepen egy import soran aztan ideposztolnad a linket

sadf -- -A -p | nc graph.sanxiago.com 443

Mongo kepes bizonyos muveleteknel 1 magot enni, ott szimplan az szamit, hogy 1 magja turbo boosttal mennyit szamol. Ezert van az, hogy nalunk gagyi 4 magos 3.4ghz e3/e5 a leggyorasabb mongo alatt.
Masik, hogy aza "Timing buffered disk reads: 368 MB in 3.01 seconds = 122.19 MB/sec" nagyon keves. Nem derul ki, hogy van-e write cache a kartyan, es engedve van-e, read az biztosan nagyon karcsu, olvasast a 64giga ram biztosan segiti, de ha kartya nincsen 2 giga flash/battery cache, akkor tetu lesz az irasod (olvasasi sebessegbol kiindulva).
Csak egy osszehasonlitasert, nalunk 8x144GB 15K sas vinyo, ami 2009ben vettunk, es hozzatartozo raid kartya, raid10-ben 700-800MB/sec produkal. Tegyel ala par ssd-t, es fenyevekkel gyorsabb lesz.

Teszt pedig insert, ami 1 magot fog terhelni, es irni fog a storage rendszerre. Hiaba van akarhany magod, es akarhany giga ramod.

Journaling paramétereket nézd meg. Az nagyban tudja az insert sebességet befolyásolni.

Mindenféle hozzá-nem-értés ellenére az elsö megérzés, hogy kb. nincs többszálú végrehajtásra optimalizálva a kód, így a sok CPU mag gyakorlatilag kihasználatlan.

--
robyboy

Tudni kellene, hogy a stage alatt milyen diszk infrastruktura van. Igy eleg nehez osszevetni a kettot.

Azt is tudni kellene, hogy a "DISK HDD" az mit takar egyik illetve masik esetben. Egy RAID 5 gyorsabb is lehet irasban, egy regi SCSI disk lassabb tud lenni, mint egy SAS diszk, raadasul az se mindegy, hogy a production rendszer alatt nem-e valami write cache-sel megtamogatott RAID megoldas van, mig a virtualis gep alatt esetlegesen csak egy nyers RAID van.

Annyi sok minden lehet, hogy ennyibol eleg nehez tippelni. Merj disk IO-t mind a ket gep esetben, hogy lasd, nem az I/O -d keves-e.
--
Blog | @hron84
Üzemeltető macik