Bigbro's foray into the scary world of blogging
05 04 2007
Due to a design decision it's a requirement that (sometimes large) binary files get stored in our CVS repository. Today, having checked in a 1.3GB binary chunk I'm not altogether entirely sure that was a good call by me. It looks like CVS server uses approximately memory equivalent to the file size for a check-in / commit operation. This is largely expected.
What I expected somewhat less was how much memory it attempts to use when checking the same file back out again, remotely, over SSH. An initial cvs process used approximately double the filesize in RAM - a whopping 2.6GB of memory, before I got a single byte of the file to my client. This was ollowed by a second process / thread being kicked off, which started to climb towards what I can only guess will be at least the size of the file in memory. The reason I don't know is because OOM killer stepped in and stopped cvs in its tracks.
Lessons learned: local checkin and checkout, on the server, for big binary files works well. This is how I'm going to get around this problem. Also, I need to upgrade our CVS server - a Linux server running 3 critical services on 256MB RAM just doesn't cut the mustard any more.
posted at: 20:12 | path: /technical | permanent link to this entry
Avast... there be some sort of Oracle off teh starboard bow...
FOr your delight and delectation, here's a collection of useful (and not quite so useful) links regarding the Oracle database platform.
