[OSM-Devserver] Wow - Load 37

[Kai Krueger]

On 04/18/2010 02:12 PM, Sven Geggus wrote:
> Tobias Wendorff<tobias.wendorff at uni-dortmund.de>  wrote:
>
>> Sieht das nicht eher wie ein Memory-Leak aus?
>
> Ein Memory leak in welchem Prozess? Seit wann führen Memory-Leaks zu
> hoher load?! Außerdem gabs keine OOM_Killer Aktion.

Der vor ein paar Tagen vergroesserte swap bereich hilft hier nicht 
unbedingt weiter. Anstelle von einzelne Processe per OOM_Killer zu 
beenden und somit das restliche System am laufen zu halten, wird nun 
moeglicherweise einfach stendig geswappt und keine der Processe kommt 
mehr voran. Jeder process der auf I/O wartet, sei es weil der Speicher 
ausgelagert wurde, erhoeht den Load um eins. Insofern kann ein memory 
leak wenn es das system in den Swap bereich treibt sehr schnell den load 
auf ueber 30 treiben.
>
>> Was sagen denn TOP&  Co.?
>
> Alles im Grünen Bereich.

Also auf  tile.osm.org ist ein load von 37 schon fast "normal" zur haupt 
zeit. Der Server laeuft trotzdem recht rund. Ein so hoher load muss also 
nicht perse eine "katastrophe" sein. 
http://munin.openstreetmap.org/openstreetmap/yevaud.openstreetmap-load.html

Dort laeuft auch sonst nichts anderes als mod_tile und renderd. Der 
rendering stack kann also schon einiges an extra load verursachen. Das 
meiste davon duerfte ebenfalls auf I/O load zurueckzufuehren sein, 
obwohl kein swapp verwendet wird.

>
> Ich fürchte aber da ist was anderes im argen:
>
> Apr 18 11:18:49 gauss kernel: [1783823.076251] INFO: task kjournald:957 blocked for more than 120 seconds.
> Apr 18 11:18:49 gauss kernel: [1783823.089858] "echo 0>  /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Apr 18 11:18:49 gauss kernel: [1783823.105873] kjournald     D 0000000000000000     0   957      2 0x00000000
> Apr 18 11:18:49 gauss kernel: [1783823.105885]  ffff8803ff0e7d40 0000000000000046 ffff8803ff0e7d00 0000000000015880
> Apr 18 11:18:49 gauss kernel: [1783823.105895]  ffff880401b8de70 0000000000015880 0000000000015880 0000000000015880
> Apr 18 11:18:49 gauss kernel: [1783823.105903]  0000000000015880 ffff880401b8de70 0000000000015880 0000000000015880
> Apr 18 11:18:49 gauss kernel: [1783823.105912] Call Trace:
> Apr 18 11:18:49 gauss kernel: [1783823.105931]  [<ffffffff811e8db6>] journal_commit_transaction+0x166/0xe60
> Apr 18 11:18:49 gauss kernel: [1783823.105943]  [<ffffffff8104f075>] ? finish_task_switch+0x65/0x120
> Apr 18 11:18:49 gauss kernel: [1783823.105953]  [<ffffffff81078a30>] ? autoremove_wake_function+0x0/0x40
> Apr 18 11:18:49 gauss kernel: [1783823.105961]  [<ffffffff8106af57>] ? lock_timer_base+0x37/0x70
> Apr 18 11:18:49 gauss kernel: [1783823.105969]  [<ffffffff8106afe7>] ? try_to_del_timer_sync+0x57/0x70
> Apr 18 11:18:49 gauss kernel: [1783823.105978]  [<ffffffff811ecc6d>] kjournald+0xed/0x250
> Apr 18 11:18:49 gauss kernel: [1783823.105986]  [<ffffffff81078a30>] ? autoremove_wake_function+0x0/0x40
> Apr 18 11:18:49 gauss kernel: [1783823.105993]  [<ffffffff811ecb80>] ? kjournald+0x0/0x250
> Apr 18 11:18:49 gauss kernel: [1783823.106000]  [<ffffffff81078646>] kthread+0xa6/0xb0
> Apr 18 11:18:49 gauss kernel: [1783823.106009]  [<ffffffff8101316a>] child_rip+0xa/0x20
> Apr 18 11:18:49 gauss kernel: [1783823.106017]  [<ffffffff810785a0>] ? kthread+0x0/0xb0
> Apr 18 11:18:49 gauss kernel: [1783823.106023]  [<ffffffff81013160>] ? child_rip+0x0/0x20
>
> Das sieht ganz so aus als ob wir da einen reboot und einen filesystem-check brauchen :(

Das kann moeglicherweise auch daran liegen das soviel Disk aktivitaet 
statt findet (durch swapp aktivitaet und DB import) das es einfach so 
lange dauert bis der filesystem commit durch ist. Es muss also nicht 
unbedingt irgendwas korrupt sein. Beende mal so viele Processe bis der 
Server nicht mehr im swap bereich ist und schau ob es besser wird.

Der Server hat ja recht wenig speicher und nicht alzu schnelle disks 
fuer was mit dem alles gemacht wird...

Kai

>
>
> Gruss
>
> Sven
>