Fórumok
Sziasztok!
Van egy webszolgáltatásunk ami az sql nagyon sokat használja a /tmp -t mivel a disk nem SSD, ezért bizonyos esetekben belassul a rendszer. (nagy méretű cache table-ket hoz létre)
Alapból 4vcpu , 8GB RAM és 4GB swap hoznánk létre a szervert, és egy 4GB ramdisket szeretnénk létrehozni.
Milyen buktatói lehetnek?
Okozhat rendszer összeomlást?
Vannak rossz tapasztalatok?
Hozzászólások
inkább növeljétek meg a (gondolom mysql) buffereit, akkor kevesebbet fog írogatni.
meg írjátok át az sql-eket jobbra.
Gábriel Ákos
Pontosan.
Amit OP ir, az kb. olyan, mint memdisk-re tenni a swapfile-t.
Én hasznlálok tmpdir-nek ramdisket, pont ilyen okból.
Gondot még nem okozott.
Nálam dedikált tmpdir van neki odaadva, nem a /tmp.
Én is ugy gondoltam, hogy pld: /mysqlramdisk -be csatolnám ,és konfigolnám a my.cnf -t.
A szükséges méretét, hogy számoltad? A fizikai RAM méretét vetted figyelembe?
Sajnos nagyon változó az adatok mérete 1MB től akár 3GB is lehet ahogy megfigyeltem.
Ha 3GB tényleg megjelenhet, akkor legalább annyival több RAM-ot kell adni és a ramdisk méretét fixálni, nehogy gondod legyen.
A swapet felejtsd el, valamennyi legyen, de úgy kell indítani, hogy 16GB RAM-ot adsz neki, ha már a 8GB-nál ez felmerül. A második lépés, hogy a mysqltuner.pl scripttel nézegeted, hogy mit javasol, mert bármilyen triviálisak is a tippek, általában elég jókat mond. A RAM diszk nem feltétlenül kell, mert tudsz ilyet mondani a MySQL-nek:
Ez után jön az, hogy meg kell vizsgálni, hogy mégis miért kell ennyit SQL-eznie az appnak, és mennyi a mindenképp szükséges adat. Jellemzően ott jön a probléma, hogy weben próbálnak millió rekordokkal "bohóckodni", mindenféle JOIN-okkal súlyosbítva. Ki szokott derülni, hogy az adatok egy jelentős része memcached/redisbe szervezhető, illetve hogy igazából a 2011-es rekordok simán archiválhatóak, esetleg törölhetőek.
Köszönöm, a mysqltuner.pl mindenképp megnézem.
Ez alapján gondoltam elkészíteni a ramdisk-et:
https://dba.stackexchange.com/questions/30505/why-does-mysql-produce-so…
Sajnos a webalkalmazás fejlesztésére nincs igazán hatásunk, github-ra tudunk max. írni.
Node nem kell ramdisk, mond neki, hogy a /dev/shm -be pakoljon, és kész. A tárolt adatokra csak van hatásotok...
Azért választanám a külön tárterületet, mert a monitoring így egyszerűbb lesz. Probléma esetén könnyebb eldönteni, hogy a rendszer más részében vagy a sql tárterületével van-e a probléma.
Teljesen más a koncepció. Ha a shm-et használsz, akkor látod, hogy ha kevés a RAM. A RAM-ot úgyis monitorozod, látsz mindent, a pillanatnyi meg üzemi állapotot. Nem szabad ennyit foglalkozni egy ilyen dologgal, legalábbis ha 4-8-16GB-os léptékről beszélünk, mert elveszel a részletekben. Amivel kéne foglalkozni szerintem, hogy a konkrét SQL-ben tárolt adatok miként tarthatóak úgy karban, hogy esetleg ne Árpád kori rekordok miatt makettezzen a professzor.
Ha pedig nagyon probléma a HDD, akkor gondolom lesz az üzleti oldalról pénz SSD-re, akár NVMe megoldásra, meg erősebb CPU-ra. Bár ezek mostanában egész értelmes áron kihozhatóak, akár a használt piacról.
Megfelelo mennyisegu memoria legyen. Az elsok kozott teszi ki swapba a "ramdisket" a rendszer ha kevesnek erzi.
Meretet meg nyugodtan lehet nagyobbat adni mert tmpfs mindig csak annyit hasznal amennyi adat van rajt fuggetlen a max merettol.
Every single person is a fool, insane, a failure, or a bad person to at least ten people.