Trac/svn seems very slow today

[robe]

Is it just me or is trac for all the OSGeo sites really slow today. Takes about 30 seconds or so for each page to load.

I tried PostGIS and OSGeo tracs.

[EliL]

Same here in Oregon. It took about 15-20 seconds just to login to make this comment.

[warmerdam]

I'm also seeing this. The VM seems busy but not apparently bogged down. I'm not sure what the bottle neck is. Anyone with skillz who can identify the problem that would be helpful.

[warmerdam]

Arg, I meant to mention that I restarted apache and it didn't help all that much.

[EliL]

Trac seems faster right now.

[neteler]

Trac is again very slow these days.

Maybe more RAM is needed for the VM?

[wildintellect]

Looking at the munin charts, I don't think that's the case. I am starting to suspect threading in apache as the issue. Are we running the multi-processor or the threaded Apache? (Look at the CPU and load, we have high load but not all CPUs seem to be in use)

Are we still running mod_python? in that case perhaps just shifting to mod_wsgi will get us increased performance.

[neteler]

It is pretty unresponsive at time: Tue Aug 21 14:06:17 UTC 2012

The connection to the server was reset while the page was loading.

[martin]

I think we need a specific, well-known test case because every time I look at the machine there's just litte to moderate CPU load, almost no swapping at all and moderate disk I/O.

markusN ?

[neteler]

Fine for test case if you tell me how..? BTW: Many people are affected, not only me.

[neteler]

Here is one:

time -p svn ci -m"docs backport of trunk r52825 + older addition" vector/v.in.ogr/description.html 
Sending        vector/v.in.ogr/description.html
Transmitting file data .
Committed revision 52828.
real 200.67  <--- !
user 0.18
sys 0.03

Ping times during commit:

[neteler@north ]$ ping www.google.com
PING www.l.google.com (173.194.35.176) 56(84) bytes of data.
64 bytes from muc03s02-in-f16.1e100.net (173.194.35.176): icmp_req=1 ttl=53 time=39.3 ms
64 bytes from muc03s02-in-f16.1e100.net (173.194.35.176): icmp_req=2 ttl=52 time=43.3 ms
64 bytes from muc03s02-in-f16.1e100.net (173.194.35.176): icmp_req=3 ttl=52 time=41.9 ms
64 bytes from muc03s02-in-f16.1e100.net (173.194.35.176): icmp_req=4 ttl=52 time=41.8 ms
^C
--- www.l.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 7067ms
rtt min/avg/max/mdev = 39.303/41.606/43.323/1.451 ms


[neteler@north ]$ ping trac.osgeo.org
PING trac.osgeo.org (140.211.15.71) 56(84) bytes of data.
64 bytes from 140.211.15.71: icmp_req=1 ttl=50 time=201 ms
64 bytes from 140.211.15.71: icmp_req=2 ttl=50 time=203 ms
64 bytes from 140.211.15.71: icmp_req=3 ttl=50 time=212 ms
64 bytes from 140.211.15.71: icmp_req=4 ttl=50 time=202 ms
^C

[robe]

Update -- trac speed seems more or less okay for me, but svn is very slow to commit, though pull down is fast. Could it be some sort of svn hook going on during commit?

[dmorissette]

See ticket #1009 about the PostGIS commit hook

[neteler]

For the GRASS GIS project, I have commented out the ciabot entry in

/var/www/svn/repos/grass/hooks/post-commit

since CIA.vc is down anyway.

[neteler]

Closing since the problem should be solved (commenting out CIA.vc posthook).