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

Adatbázis: SQL, XML DB

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)

  • 4500 megtekintés

( atomheart v | 2017. 02. 14., k – 17:40 )

"Disk HDD"

Milyen HDD milyen RAID-ban?

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

( fathom | 2017. 02. 14., k – 17:41 )

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

( andrej_ v | 2017. 02. 14., k – 17:43 )

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

( lmarton | 2017. 02. 14., k – 17:54 )

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.

( SzBlackY | 2017. 02. 14., k – 18:31 )

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)

( freeoli v | 2017. 02. 14., k – 18:48 )

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.

( dotnetlinux | 2017. 02. 14., k – 19:07 )

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

( NevemTeve | 2017. 02. 14., k – 21:51 )

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.

( golgota | 2017. 02. 15., sze – 09:47 )

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.

( klixnetwork | 2017. 02. 15., sze – 15:36 )

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

( Sea-you | 2017. 02. 15., sze – 17:58 )

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

( bubor | 2017. 02. 15., sze – 19:02 )

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.

( systream | 2017. 02. 17., p – 08:37 )

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

( uid_16313 | 2017. 02. 17., p – 13:27 )

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

( hrgy84 | 2017. 02. 17., p – 14:09 )

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