{"thread":{"id":"3919","subject":"git-daemon memory usage, disconnection.","startedAt":"2006-04-19T13:22:46Z","lastAt":"2006-04-19T15:49:09Z","messageCount":4,"participants":["David Woodhouse","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"18873","messageId":"1145452967.13200.92.camel@pmac.infradead.org","threadId":"3919","inReplyTo":null,"subject":"git-daemon memory usage, disconnection.","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2006-04-19T13:22:46Z","receivedAt":"2006-04-19T13:22:46Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"I'm running git-daemon from xinetd and it seems a little greedy...\n\nCpu(s):  2.7% us,  6.4% sy,  0.0% ni,  1.7% id, 87.7% wa,  1.4% hi,  0.0% si\nMem:    253680k total,   250076k used,     3604k free,      568k buffers\nSwap:   500960k total,   500864k used,       96k free,    24696k cached\n\n  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND\n31232 nobody    18   0  155m  29m 7224 D  1.3 11.9   0:25.56 git-rev-list\n30743 nobody    18   0  179m  29m 9480 D  0.7 11.9   0:42.60 git-rev-list\n31277 nobody    18   0  147m  28m 7476 D  2.6 11.4   0:20.90 git-rev-list\n30314 nobody    18   0  233m  26m 7696 D  0.0 10.6   1:20.24 git-rev-list\n30612 nobody    18   0  204m  23m 7432 D  1.3  9.4   0:59.19 git-rev-list\n30574 nobody    18   0  190m  20m 7608 D  0.3  8.3   0:50.77 git-rev-list\n30208 nobody    18   0  140m  14m 7632 D  0.3  5.9   0:15.23 git-pack-object\n\nNow, this wouldn't be _so_ bad if there were only two of them running.\nThe clients for the other four have actually given up and disconnected\nlong ago, but git-daemon doesn't seem to have reacted to that.\n\n-- \ndwmw2\n"},{"id":"18878","messageId":"Pine.LNX.4.64.0604190749160.3701@g5.osdl.org","threadId":"3919","inReplyTo":"1145452967.13200.92.camel@pmac.infradead.org","subject":"Re: git-daemon memory usage, disconnection.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-19T14:59:43Z","receivedAt":"2006-04-19T14:59:43Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 19 Apr 2006, David Woodhouse wrote:\n>\n> I'm running git-daemon from xinetd and it seems a little greedy...\n> \n> Cpu(s):  2.7% us,  6.4% sy,  0.0% ni,  1.7% id, 87.7% wa,  1.4% hi,  0.0% si\n> Mem:    253680k total,   250076k used,     3604k free,      568k buffers\n> Swap:   500960k total,   500864k used,       96k free,    24696k cached\n> \n>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND\n> 31232 nobody    18   0  155m  29m 7224 D  1.3 11.9   0:25.56 git-rev-list\n> 30743 nobody    18   0  179m  29m 9480 D  0.7 11.9   0:42.60 git-rev-list\n> 31277 nobody    18   0  147m  28m 7476 D  2.6 11.4   0:20.90 git-rev-list\n> 30314 nobody    18   0  233m  26m 7696 D  0.0 10.6   1:20.24 git-rev-list\n> 30612 nobody    18   0  204m  23m 7432 D  1.3  9.4   0:59.19 git-rev-list\n> 30574 nobody    18   0  190m  20m 7608 D  0.3  8.3   0:50.77 git-rev-list\n> 30208 nobody    18   0  140m  14m 7632 D  0.3  5.9   0:15.23 git-pack-object\n\nWell, you've probably got two issues: \n\n - it looks like you aren't packing your archives (which explains why the \n   disk accesses are horrid, which in turn explains the \"D\" part).\n\n   For a git server, you _really_ want all trees to be mostly packed, or \n   you want absolutely tons of memory (and 256kB is definitely not \"tons\"\n   as far as git is concerned).\n\n - git-rev-list won't notice that there is nobody listening until it gets \n   a EPIPE, and it won't get an EPIPE until it actually outputs something, \n   and it won't output anything until it is largely done traversing the \n   tree..\n\n> Now, this wouldn't be _so_ bad if there were only two of them running.\n> The clients for the other four have actually given up and disconnected\n> long ago, but git-daemon doesn't seem to have reacted to that.\n\nWell, the way things work under UNIX, you normally don't notice that the \nother end isn't interested until you try to write, and you get a \"nobody \nis listening\". And sadly, the packing stuff does most (not all) of the \nheavy lifting before it can even start to write things out.\n\nThat said, I should probably take a look at git-rev-list --objects memory \nusage once again. It's neve rbeen exactly \"lean\" (and it can't really be: \nit does end up needing the total object list in memory for a full clone, \nand with something like the kernel, that's about 250 _thousand_ objects).\n\nWe should probably also make send-pack.c use the nice revision library, \nbecause right now it's doing that pipe to git-rev-list for no good reason.\n\n\t\tLinus\n"},{"id":"18879","messageId":"1145460469.11909.25.camel@pmac.infradead.org","threadId":"3919","inReplyTo":"Pine.LNX.4.64.0604190749160.3701@g5.osdl.org","subject":"Re: git-daemon memory usage, disconnection.","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2006-04-19T15:27:49Z","receivedAt":"2006-04-19T15:27:49Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Wed, 2006-04-19 at 07:59 -0700, Linus Torvalds wrote:\n> Well, you've probably got two issues: \n> \n>  - it looks like you aren't packing your archives (which explains why the \n>    disk accesses are horrid, which in turn explains the \"D\" part).\n\nHm, good point. They're fairly new trees -- I had foolishly assumed that\nthey would at least start off packed. That isn't the case though --\nperhaps it should be? Did the original clone receive a pack on the wire\nand then _split_ it?\n\nIf the tools would automatically pack when the number of unpacked\nobjects reaches a threshold, that would be useful.\n\nSince this repo is only available through git:// and git+ssh:// URLs, I\ncan safely use git-repack's '-a -d' options, right?\n\nI'll do 'git-repack -l' nightly and 'git-repack -a -d -l' weekly -- does\nthat seem sane?\n\n>    For a git server, you _really_ want all trees to be mostly packed, or \n>    you want absolutely tons of memory (and 256kB is definitely not \"tons\"\n>    as far as git is concerned).\n> \n> Well, the way things work under UNIX, you normally don't notice that the \n> other end isn't interested until you try to write, and you get a \"nobody \n> is listening\". And sadly, the packing stuff does most (not all) of the \n> heavy lifting before it can even start to write things out.\n\nWell, it does that with SIGALRM happening periodically, theoretically\nfor the purpose of providing progress output. Perhaps we could do a\ngetpeername() or something else to check on the output fd each time?\n\n-- \ndwmw2\n"},{"id":"18880","messageId":"Pine.LNX.4.64.0604190839380.3701@g5.osdl.org","threadId":"3919","inReplyTo":"1145460469.11909.25.camel@pmac.infradead.org","subject":"Re: git-daemon memory usage, disconnection.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-19T15:49:09Z","receivedAt":"2006-04-19T15:49:09Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 19 Apr 2006, David Woodhouse wrote:\n\n> On Wed, 2006-04-19 at 07:59 -0700, Linus Torvalds wrote:\n> > Well, you've probably got two issues: \n> > \n> >  - it looks like you aren't packing your archives (which explains why the \n> >    disk accesses are horrid, which in turn explains the \"D\" part).\n> \n> Hm, good point. They're fairly new trees -- I had foolishly assumed that\n> they would at least start off packed. That isn't the case though --\n> perhaps it should be? Did the original clone receive a pack on the wire\n> and then _split_ it?\n\nFor old versions of git, yes.\n\n> If the tools would automatically pack when the number of unpacked\n> objects reaches a threshold, that would be useful.\n\nWell, packing is still best done in the background: you don't generally \nwant the tools to just stop for a minute to repack while you're doing \nsomething. You'd normally want to do a cron run at 4AM or something, see \nif there is lots to pack, and repack that.\n\nThe one exception is probably a large conversion process (from CVS, SVN, \nwhatever). The conversion process itself probably takes ages, and it will \nbe even slower if it were to keep the potentially huge result unpacked all \nthe time.\n\nBut for normal ops, you really don't want to repack synchronously.\n\n> Since this repo is only available through git:// and git+ssh:// URLs, I\n> can safely use git-repack's '-a -d' options, right?\n\nYes.\n\n> I'll do 'git-repack -l' nightly and 'git-repack -a -d -l' weekly -- does\n> that seem sane?\n\nAbsolutely. The one exception might be trees that really don't change very \nmuch (which is quite common), so you might make it conditional on seeing \nif there are _any_ objects at all in .git/objects/00/, for example. Not \nthat repack will be very expensive, but still..\n\n> Well, it does that with SIGALRM happening periodically, theoretically\n> for the purpose of providing progress output. Perhaps we could do a\n> getpeername() or something else to check on the output fd each time?\n\nYes, that's possibly a good idea. Of course, for git-rev-list, it's just a \npipe, and it's hard to do that check at least portably. On Linux, doing a \n\"poll()\" on a pipe for writing, with newer kernels you'll get a POLLERR if \nthe other side has hung up, but that's by no means portable.\n\n(On some other systems, doing a zero-sized write() _might_ do it, but at \nleast Linux will happily say \"ok, wrote 0 bytes\" even if the other end \nisn't listening).\n\nAnd git-rev-list isn't doing the SIGALARM anyway.\n\nIn other words, to do this, we'd have to change send-pack to use the \nrevision library. Which, as mentioned, is worth-while anyway, but it's not \ntotally trivial.\n\n\t\tLinus\n"}]}