+++ Simon Michael [Apr 15 09 09:51 ]: > Also, it was using 3% cpu continuously. After running overnight, it > was using 30% continuously (ouch), with 264M resident ram. I don't > think it was serving many requests, I have enabled more verbose > logging now. There were two "HTTP request failed with: <socket: 6>: > hLookAhead: resource vanished (Connection reset by peer)" warnings on > the console, that's probably normal.
The console warnings are normal. The CPU and memory usage are unexpectedly high. My demo instance at gitit.johnmacfarlane.net uses 1% of CPU and around 91M RAM. My instance uses a git filestore, though, not darcs. I think the difference might be attributable to inefficiencies in darcs filestore. Currently the command to get information on the latest revision has to parse the entire output of 'darcs changes', which is pretty long for your wiki. It seems there is no way to get 'darcs changes' to return just the most recent change that touches a specified file. (You'd think '--last=1' would do this, but it doesn't -- it seems to count back in the global patch stack, rather than in the patches that touch the specified file.) Since getting latest revision info is a fairly common task in gitit, this could be slowing things down considerably, and causing high CPU usage. Just a guess, though. Gwern has just sent me a patch to filestore that should make the 'retrieve' operation more efficient, but there will still be inefficiencies in 'latest'. I think I see a way to make that slightly more efficient, but I don't know how to make it much more efficient with the current options in 'darcs changes'. John _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
