VPS-en out of memory

Linux-kezdő

Sziasztok!

Adott egy VPS. 6 GB RAM-al, 4 magos AMD Opteronnal, 64 bites Debian Wheezy-vel.

Ezen apache2 és mysql fut. A gép ma reggel azzal fogadott, hogy teljesen meghalt. Újraindítottam, most működik. De a kern.log-ban ezt találtam:


root@tegyjotadrienn:~# cat /var/log/kern.log
Jun 8 23:32:29 tegyjotadrienn kernel: [975568.012512] Out of memory in UB 193: OOM killed process 109 (upstart-udev-br) score 0 vm:16988kB, rss:84kB, swap:212kB
Jun 8 23:32:29 tegyjotadrienn kernel: [975568.039689] Out of memory in UB 193: OOM killed process 263 (upstart-socket-) score 0 vm:14936kB, rss:40kB, swap:236kB
Jun 9 02:44:42 tegyjotadrienn kernel: imklog 5.8.11, log source = /proc/kmsg started.

Ha jól látom az udev nyírta ki? Vagy merre keresgéljek?

Update: Kértem és kaptam bővebb infót a szolgáltatótól. Ezzel a loggal szolgált: http://pastebin.com/T9FHh9sG

  • 8136 megtekintés

( andrej_ v | 2014. 06. 09., h – 16:38 )

Ez milyen virtualizáción megy? Alaphelyzetben milyen a memória felhasználás és monitorozod-e muninnal mondjuk, hogy mi történik a gépen?

( r2d2joda | 2014. 06. 10., k – 11:56 )

Sajnos sok VPS szolgáltató több erőforrást ajánl ki, mint amennyivel rendelkezik az adott hardver.
"úgyse használja mindenki az összes erőforrást egyszerre címszóval" 64Gb ramot el tudnak adni 90Gb nak is
Példának a te vps-ed 6Gb ramos, egy 64Gb rammal szerelt szerverben 10 db VPS tudna elfutni normálisan garantált ram kiosztással. A VPS árakat az olcsójánosok úgy letornázták, hogy ebből az olcsó szolgáltatók nem élnek meg.

Ezért a ramot többszörösen eladják. Az ügyfeleknek a 6Gb ramból garantáltan adnak 3Gb ramot, így pl 15 ügyfélnek tud ugyanazzal a 64Gb rammal szerelt szerveren 6GB ramos vps-t adni.
A fennmaradó 18GB memória területből az összes vps igényelhet, ha a VPS-ek fele igényli egyszerre az összes ramot, akkor elfogyott a ram, és véletlenszerűen lehalnak a VPS-ek.

Ha van munin-od akkor tudod nézni, hogy ténylegese fel tudod-e használni azt a ramot ami "látszik".
Olcsó VPS-nél sok jóra ne számíts.

Jaja, nekem is van a DO-nál egy-két gép, kíváncsi leszek, mi lesz velük egy-két év múlva (mármint a DO-val, nem a VM-ekkel). Látszólag sem a tech, sem a support részen nem spóroltak nagyot, és úgy tűnik, nyereségük is van, mert nyitogatják azért az adatközpontokat elég szépen.

Valószínűleg a DO az egyik kivétel, de ha megnézel egy <1000 forintos, magyar VPS-t (eleve alig van ilyen), akkor az egy fos lesz.

ebben sok minden közrejátszik, pl. magyar adórendszer áfa stb. De az is igaz hogy itt az 1000ft os vps kb annyi hogy pistike kiteszi a standalon gépet ESXi-vel, oszt jónapot.

Kint nagyon nagy az automatizáltság, elején beleölnek csomó pénzt, aztán pár ember elüzemelteti az egészet. A legtöbb mai magyar VPS szolgáltató kézzel buherál mindent.

Fedora 20, Thinkpad x220

Ez már bőven változóban van. Hirtelen legalább 4 hazai VPS szolgáltatót tudok, ahol komoly vagy teljes az automatizáltság, tehát nem kéne lesajnálni a hazai viszonyokat. Én meg személy szerint jobban szeretem a kézihajtányt, mert legalább tudom mi történik, ezért nálunk marad egyelőre ez...

Najó, de ha nincs annyi?
Nálunk a desktopokra megcsináltam egy központi telepítő-frissítő-miegyéb scriptet-megoldást, de mivel kevés desktop van (kb. 20), és annak is egy része kint van partnernél, akár annyira, hogy az ottani emberke telepít rá már az OS-től kezdve, így több meló lenne karban tartani a központi managementet mint kézzel telepítgetni ha épp kell valami.

Magyarországról beszélünk és megint léptéktévesztés van. :) Nem tudom kinek mennyi gépe van, de amit látok azaz, hogy 3-4-5 géppel is borzasztó mennyiségű VPS szolgálható ki gond nélkül. Nyilván egy Linode vagy RackSpace megbolondulna, ha a sokezer vasat kézzel kéne nyomkodni.

Igen, az hogy szeretem óriási érv, mert azt tudom normálisan üzemeltetni és még ha szeretném a klikkelést pivit, akkor sajnos kapacitás nem lenne az újításhoz.

Igen, magyarországi viszonyok, többek közt ezért nem lesz itt még jó darabig rackspace vagy hasonló méretű cég. Azért itt a hupon is vannak páran akik külföldön tartják a VPS-t. Gondolom nem csak az ár miatt. Hanem mert szeretnék magunak állítani tűzfalat, vagy maguknak installálni, vagy akár maguknak állítani belső hálózatot.

Az, hogy egy VPS-t automatán hoz létre valami nagyon messze van az IaaS-től. Nem tudom van rendes IaaS szolgáltató magyarországon.

Fedora 20, Thinkpad x220

Aztán eljön egy olyan állapot, amikor az automatizáció keresztbeáll. :) A kedvenc példám az MS Azure-os tanusítvány cserés történet, illetve másik konkrét eset amikor még 2-3 gépes clusterek is le tudják dobni a láncot bizonyos körülmények között. Ahogy már írtam adott üzemméret felett nem lehet megkerülni az automatizációt, ezzel egyetértek, de azért én óvatos vagyok.

Hmm... az Azure-os eset nekem is megvan, de ott nem az automatizmus okozta a legnagyobb gondot.

Ott az volt a gáz, hogy miközben a fabric controller éppen azzal foglalkozott, hogy szétverje az clustereket, még elkezdtek teríteni egy update-et is, hadd fájjon. Érdekes olvasmány egyébként, a devportálos ingyenes azure könyv 52. oldalától

Nem is ez az alapveto gond, hanem az, hogy egy meglevo rendszerbe automatizalast bevezetni rettenetesen szar dolog, mert mar van egy csomo (valoszinuleg hibas) scenario, amit semmilyen automatizalo cucc nem fog elkezelni neked, es akkor kezdodik a nyuglodes, hogy ezt igy megis hogy.

Mig ha az elejetol van _valamilyen_ automatizalas, akkor igazabol csak az a kerdes, hogy OnApp-ra terj at, vagy OpenStackre, vagy Eucalyptus-ra.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Ez erősen technológia függő is. Az OpenVZ vonallal szeretnek mindent overbookolva eladni, de cserébe olcsó. Ha Xen vagy VMWare, akkor ott fix kiosztás van. A diszk IO és a CPU már itt is overbookolható, de a VPS-ek nagytöbbsége minimális CPU-val elszalad.

A memóriáról meg annyit, hogy ha már 64GB van a gépben, akkor az eleve egy komolyabb konfigot feltételez amibe relatív olcsón akár 256G is pakolható.

( kroozo v | 2014. 06. 16., h – 17:17 )

csak mert látom, technikai vonalon nem volt válasz:

nem az udev nyírta ki, hanem az OOM, mert elfogyott a memó. Az OOM az mondjuk, hogy a kernel kisbaltás rendcsináló bácsija, mikor már nagyon nincs memó, és kéne, akkor jön, és lecsapkod kb random processzeket, hogy legyen. Esetünkben az látszik, hogy köszönettel, de igen jól célzott, és az upstart két alkatrészét csapta agyon. Most fejből nem tudom, miért felelnek, de jó nem sül ki belőle, az szinte tuti.

Hogy a mem azért fogyott ki, mert tényleg kifeszegetted a korlátot, vagy azért, mert a hypervisor fogyott ki fizikailag, az ebből passz. Egy kis swap file segíthet ilyenkor, de leginkább megnézni, hogy nem kell-e nagyobb doboz, vagy nem lehet-e optimalizálni, mert azzal max azt lehet elérni, hogy ilyenkor nem halljon szét a cucc, csak belassuljon.

a pastebin meg sajna nem látszik....

Ebből én nem feltétlen látom, hogy a guest vagy a host fogyott ki.

Bár, ha onnan közelítek, hogy openvz van, akkor ott egy kernel van, egy oom, és mivel nem saját limitje fogyott el (beancounter) hanem oom irtott valamit, ebből arra tudok jutni, hogy bizony a host fogyott ki, ami a szolgáltató hibája és sűrű elnézéseket kell kérjen. És guesten nem is tudom, hogy tud-e swapfile-t beállítani illetve van-e annak bármi valódi értelme.

--
Gábriel Ákos
http://i-logic.hu

Ami gond lehet, hogy hagyományos gép esetén egy processz malloc-ot kérhet több mennyiségű memóriára mint akár a swap+RAM együtt és ez hiba nélkül lefut.
Azonban OpenVZ és Virtuozzó esetén fail lesz egy ilyen jellegű malloc.

Az oom killer akkor is írt, ha a konténer saját erőforrása fogy el (elég ehhez egy leakelő php alkalmazás).

( szs v | 2014. 06. 17., k – 08:01 )

Teljesen véletlenül nem egy magyar szolgáltató, aminek a neve úgy kezdődik, hogy integ?

( hrgy84 | 2014. 06. 17., k – 12:45 )

This paste has been removed!

(valoszinuleg anonimizalni kellene...)
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.