OpenVZ - Cannot allocate memory

Virtualizáció

Egy relatív nagy cégnél ( nem garázs kategória ) bérlünk néhány VPS -t. Egyelőre nem szeretnék nevet említeni.
Az a gond, hogy ha megpróbálok több RAM -ot elfoglalni a gépen ( 60% + ), akkor Cannot allocate memory hibával elszáll az app, annak ellenére, hogy még van egy rakás szabad hely. Írtam a support -nak, ők azzal oldották meg, hogy adtak swap -ot, de szerintem ez nem az igazi. Mieőtt elkezdenék jobban panaszkodni az szeretném tudni, hogy igazam van, vagy az OpenVZ esetében az 1Gb RAM, az nem 1Gb ( pl bizonyos OS process -eket en nem látok, de elfoglalja a memóriát ).
A RAM az garantált 1Gb ( nem burstable ). Szerintem több mint valószínü, hogy ők trükköznek valamit, de előbb meg szerettem volna kérdezni a nagyérdeműt.
Köszönöm!

Ezek az adatok meg a swap létezése előttiek:

# stress --vm 2 --vm-bytes 250M --timeout 10s
stress: info: [4367] dispatching hogs: 0 cpu, 0 io, 2 vm, 0 hdd
stress: FAIL: [4368] (495) hogvm malloc failed: Cannot allocate memory
stress: FAIL: [4367] (395) <-- worker 4368 returned error 1
stress: WARN: [4367] (397) now reaping child worker processes
stress: FAIL: [4367] (452) failed run completed in 0s

#free -m
total used free shared buffers cached
Mem: 1024 556 467 0 0 328
-/+ buffers/cache: 227 796
Swap: 0 0 0

vmstat -s
1048576 K total memory
570224 K used memory
430028 K active memory
124732 K inactive memory
478352 K free memory
0 K buffer memory
337048 K swap cache
0 K total swap
0 K used swap
0 K free swap
3123149 non-nice user cpu ticks
2603 nice user cpu ticks
577221 system cpu ticks
1802164518 idle cpu ticks
4306327 IO-wait cpu ticks
0 IRQ cpu ticks
0 softirq cpu ticks
0 stolen cpu ticks
287080164 pages paged in
343489320 pages paged out
28702 pages swapped in
25742 pages swapped out
0 interrupts
669704461 CPU context switches
1444077898 boot time
1449849 forks

cat /proc/user_beancounters
Version: 2.5
uid resource held maxheld barrier limit failcnt
116088: kmemsize 12889646 44695552 9223372036854775807 9223372036854775807 0
lockedpages 724 806 262144 262144 0
privvmpages 167093 262144 262144 262144 3047
shmpages 10508 17546 9223372036854775807 9223372036854775807 0
dummy 0 0 9223372036854775807 9223372036854775807 0
numproc 76 183 9223372036854775807 9223372036854775807 0
physpages 223190 262210 262144 262144 0
vmguarpages 0 0 262144 9223372036854775807 0
oomguarpages 68632 148935 262144 9223372036854775807 0
numtcpsock 57 84 9223372036854775807 9223372036854775807 0
numflock 8 14 9223372036854775807 9223372036854775807 0
numpty 2 10 9223372036854775807 9223372036854775807 0
numsiginfo 0 27 9223372036854775807 9223372036854775807 0
tcpsndbuf 2141872 11423520 9223372036854775807 9223372036854775807 0
tcprcvbuf 953904 6798272 9223372036854775807 9223372036854775807 0
othersockbuf 57024 343968 9223372036854775807 9223372036854775807 0
dgramrcvbuf 0 188048 9223372036854775807 9223372036854775807 0
numothersock 39 212 9223372036854775807 9223372036854775807 0
dcachesize 6870816 38070645 9223372036854775807 9223372036854775807 0
numfile 1136 1455 9223372036854775807 9223372036854775807 0
dummy 0 0 9223372036854775807 9223372036854775807 0
dummy 0 0 9223372036854775807 9223372036854775807 0
dummy 0 0 9223372036854775807 9223372036854775807 0
numiptent 24 33 9223372036854775807 9223372036854775807 0

  • 1422 megtekintés

( csardij v | 2015. 12. 03., cs – 11:07 )

Helló,

Attól, hogy nem burstable a ram (főleg, hogy ez a fogalom már a centos6 óta nincsen) még lehet, hogy a szerver fizikai memóriája fogyott el.

A szerveren PHP + MySQL fut. Nagyon kevés oldalletöltés van, csak nagyocska az adatbazis ( < 10.000.000 sor ) és egy komplexebb query -nek kellhet néhány másodperc. Más vason ( több RAM, de lassúbb lemez ) nagyon hamar lefut. Ez lényegtelen, a kerdés az az, hogy van jogom panaszkodni, hogy nem tudom kihasználni a garantált RAM -ot vagy sem. :)

Most már értem, hogy mire céloztál. Nem mondanám, hogy drága, de lehet sokkal olcsóbbat is találni. Ez 10USD ( 1Gb RAM, 30GB tárhely ). Az egyik szempont ami miatt őket választottuk, hogy az adatközpontjuk nagyon közel van a klienshez. Költozni nem szeretnénk, mert nagyon macerás lenne.
A lényeg, hogy virtualizáció típusától függetlenül jár az ígért RAM mennyiség.

( Proci85 v | 2015. 12. 03., cs – 12:13 )

OpenVZ-vel ~2010 körül futtottam bele hasonlóba. Adott alkalamzás 2-3, ritkán 5x nagyobb RAM-ot kért, mint KVM-ben vagy XEN-ben futva.
Ezt a hupra is feldobtam és többen megerősítették, hogy nem minden esetben, de jártak már így.
Konkrétan egy 256MB-s XEN-es virtuális gépet OpenVZ-re migráltam át, és mindig out of memoryval elszálltak a programok. Már 1-1.5 GB RAM-nál jártam, mire elég volt neki.
Vissszaraktam XEN alá és elég lett 256 MB RAM is. Ez egy LAMP környezet volt.

Amúgy meg lehet, hogy burstolt ramot kaptál...
A fentiek miatt személyes véleményem az, hogy az OpenVZ-t komoly dolgokra ne használja az ember. És még nem is beszéltem arról, hogy közös kernelt kell használni. ( vagy az elmúlt 6 évben megoldották már?)

Nem biztos, hogy a legjobb megoldast mondom (sot, biztos, hogy nem), de a Docker egy egesz erdekes kis variacioja a virtualizacionak...

Ugyanakkor azt szerintem latni kell, hogy ami PV annal a kernel ugyanaz mint a vason...
Ami HV annal mar barmi lehet... :)

Szoval az OpenVZ szerintem nem fog tudni mas kernelt adni a VM ala...

Ha hulyeseget irok, akkor bocs :)

--
Debian Linux rulez... :D

Mi 2006 környékén teszteltük hogy mivel virtualizáljunk. xen/openvz Az openvz nagyon furcsaságokat csinált már akkor is, meg ugye pár kritérium pl saját kernel modul stb elég macerás volt. Így maradt a xen, amit azóta is használunk és nem bántunk meg.

Fedora 22, Thinkpad x220