Planlagt arbejde på serveren

[NickyThomassen]

Jeg tror problemet ligger imellem nginx og php5-fpm uden at det nødvendigvis er nogen af programmernes skyld. På postfix-users postlisten har det været oppe og vende at nginx ikke er god som proxy til email. Grunden er åbenbart at den overholder standarderne og at udviklerne ikke vil lave lave kludges for at fikse ting og sager.

Egentlig er jeg også overrasket over hastigheden, for jeg har på ingen måde forsøgt at optimere Apache. Et opstået problem er derimod at Apache har fået Linux til at overcomitte, noget jeg nok kigger på ved lejlighed så OOM ikke kommer frem fra dybet. Ved samme lejlighed skifter jeg nok over til MPM Event, for den skulle kunne parkere alle keep alive forbindelser i en billig tråd så de noget dyrere server tråde kan bruges til at levere indhold
https://httpd.apache.org/docs/2.4/mod/event.html

Under en af søgningerne fandt jeg en noget humoristisk måde at kritisere overcommit og OOM

An aircraft company discovered that it was cheaper to fly its planes
with less fuel on board. The planes would be lighter and use less fuel
and money was saved. On rare occasions however the amount of fuel was
insufficient, and the plane would crash. This problem was solved by
the engineers of the company by the development of a special OOF
(out-of-fuel) mechanism. In emergency cases a passenger was selected
and thrown out of the plane. (When necessary, the procedure was
repeated.) A large body of theory was developed and many publications
were devoted to the problem of properly selecting the victim to be
ejected. Should the victim be chosen at random? Or should one choose
the heaviest person? Or the oldest? Should passengers pay in order not
to be ejected, so that the victim would be the poorest on board? And
if for example the heaviest person was chosen, should there be a
special exception in case that was the pilot? Should first class
passengers be exempted? Now that the OOF mechanism existed, it would
be activated every now and then, and eject passengers even when there
was no fuel shortage. The engineers are still studying precisely how
this malfunction is caused.

http://lwn.net/Articles/104185/

[NickyThomassen]

... Apache har fået Linux til at overcomitte ...

Med ikke mindre end 25% / 250mb i øvrigt

memory-week.png (52.32 KiB) Vist 723 gange

[lath]

... Apache har fået Linux til at overcomitte ...

Med ikke mindre end 25% / 250mb i øvrigt

memory-week.png

overcommit er ikke et problem så længe at alle programmet samlet set ikke bruger den overcomittede virtulle hukommelse på en sådan måde at al fysisk RAM + swap resulterer i thrashing, således at OOM killer algoritmen i kernen bliver aktiveret - efter nogen tid , f.eks 1/2 minut.

I standard overcommit mode, så vil kernen fungere sådan at den først allokerer fysisk RAM, når programmet skriver til en page, der ikke allerede er mapped til en page i fysisk RAM eller en page i swap.
I praksis betyder det at når et program bruger overcommitet virtuel hukommelse at der ikke er et tilsvarende forbrug af fysisk RAM og/eller swap.

Begrænsning i overcommit er fordelagtigt, hvis et program ikke fungerer korrekt.
Fordelen er at allokerring af en eller flere pages i fysisk RAM via virtuel hukommelse fejler når programmet beder kernen om at allokere mere hukommelse til programmet - i stedet for at der opstår hukommelses relaterede fejl meget længe efter at der er allokeret (overcommittet) virtuel hukommelse.

overcommit kan styres via sysctl og via /etc/sysctl.conf

Nogle links der kan være interessante:

• https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
• http://tonylixu.blogspot.dk/2014/01/linux-kernel-tuning-swappiness-and.html
• http://serverfault.com/questions/362589/effects-of-configuring-vm-overcommit-memory

/Lars

[NickyThomassen]

... Apache har fået Linux til at overcomitte ...

Med ikke mindre end 25% / 250mb i øvrigt

memory-week.png

overcommit er ikke et problem så længe at alle programmet samlet set ikke bruger den overcomittede virtulle hukommelse på en sådan måde at al fysisk RAM + swap resulterer i thrashing, således at OOM killer algoritmen i kernen bliver aktiveret - efter nogen tid , f.eks 1/2 minut.

Mange tak for svaret igen. Det er ganske spændende læsning hvordan kernen forsøger at løse problemer af den her type. Især fordi der ikke er nogen god løsning.

Sådan set har jeg heller ikke et problem med overcommit, ligesom at jeg syntes standard swappines i Linux fungerer fint. De få gange jeg har blandet mig i swap har jeg helt deaktiveret partitionen med swap, men det er ikke noget jeg ville gøre med et system som må forventes at have en høj oppetid.

Problemet her er at det er Apaches processer som får Linux til at overcommitte. Da vi er nødt til at planlægge på en 100% brug af Apaches processer plejer løsningen at være en begrænsning af Apache som er stor nok til at der også er plads til filcache i ram. Efter den justering ser ramfordelingen sådan her ud

memory-day.png (55.97 KiB) Vist 677 gange

Apache burde stadig blive justeret lidt ned, men i forhold til tidligere hvor vi risikerede en 125% brug af ram, så risikerer vi kun omkring 100% nu hvis Apache bruger alle sine processer på én gang.

php5-fpm virkede i øvrigt heller ikke med Apaches MPM Prefork, så allerede i søndags skiftede jeg til mod_php. Siden da har serveren kørt stabilt og uden synlige problemer.