It seems that our memory estimation of what the hg machine would need was wildly incorrect, causing an OOM Linux crash within one hour. We'll look into fixing this; expect occasional 15 min outages for a few days for reboots. If the outage is longer, it means it crashed again :-( I'll report if we found something that can be considered a permanent solution.
Regards, Martin
Le lundi 02 juillet 2012 à 00:48 +0200, "Martin v. Löwis" a écrit :
It seems that our memory estimation of what the hg machine would need was wildly incorrect, causing an OOM Linux crash within one hour. We'll look into fixing this; expect occasional 15 min outages for a few days for reboots. If the outage is longer, it means it crashed again :-( I'll report if we found something that can be considered a permanent solution.
The machine now has double the RAM (8 GB) and the biggest memory hog has been turned into a sober process (2 GB down to 80 MB). Things should be much better :-)
Regards
Antoine.
On 02.07.2012 00:48, "Martin v. Löwis" wrote:
I'll report if we found something that can be considered a permanent solution.
Antoine managed to reduce the memory usage of Mercurial quite drastically. Not sure which contributed most, but a) hg was upgraded to 2.2 b) a patch was applied to hgweb which calls repo.invalidate/gc.collect after each request (IIUC) c) reducing the memory consumption of our hglookup binary (which maps revision numbers to repositories) d) improving the hgweb rejuvenation
With that, hg.p.o should be quite available and responsive; if it isn't, please report the infrastructure list.
Regards, Martin
participants (2)
-
"Martin v. Löwis" -
Antoine Pitrou