When you say "cached memory" do you mean the "cached" column as shown in the
output of 'free'? If so, then it sounds like this is working perfectly. Any
proper kernel (Linux, Windows, etc) uses what would be otherwise unused
memory pages to cache files on disk. This is a good thing. Having memory
truly "free" is actually a _waste_, since ideally you could be using to
speed something up. Why deleting your repository "fixed" this is because
Linux realized the cache was no longer needed.
So this isn't a bug, or even a problem. This is the Linux kernel making your
computer faster!
Jason Malinowski
> -----Original Message-----
> From: Murat Arslan [mailto:arslanm_at_gmail.com]
> Sent: Wednesday, July 15, 2009 2:17 PM
> To: users_at_subversion.tigris.org
> Subject: Subversion memory problem
>
> Hi,
>
> This might be a popular topic, but I couldn't find a solution
> anywhere. Trying my chance here.
>
> The system is a 2GB ram RHEL 5 32bit Linux. Recently built. Standard
> installation plus Subversion. Some important packages:
>
> subversion-1.6.3-0.1.el5.rf-i386
> neon-0.25.5-10.el5-i386
> httpd-2.2.3-22.el5_3.2-i386
> mod_ssl-2.2.3-22.el5_3.2-i386
> python-2.4.3-24.el5-i386
> mod_python-3.2.8-3.1-i386
>
> It's kind of irrelevant, but problem also exists on http/mod_svn, so
> here is some related Apache config:
>
> Related Apache config:
> <IfModule prefork.c>
> StartServers 10
> MinSpareServers 10
> MaxSpareServers 20
> ServerLimit 200
> MaxClients 200
> MaxRequestsPerChild 500
> MaxMemFree 128
> </IfModule>
>
> SVN config for Apache:
>
> <Location /svn/mytest>
> DAV svn
> SVNPath /opt/app/svn/mytest
> SVNPathAuthz off
> SVNAllowBulkUpdates off
> AuthType Basic
> AuthName "mytest"
> AuthzSVNAccessFile /opt/app/svn/svn-acl.conf
> AuthUserFile /opt/app/svn/mytest.htpasswd
> Require valid-user
> </Location>
>
> Problem description:
>
> Whenever I import a >200MB total size of files (thousands of them) to
> a repository, the system won't release the cached memory when the
> import is finished.
>
> Example: Before import, cached memory is about 100M. I import Windows
> 2003 R2 installation CD contents using TortoiseSVN with
> authentication, takes about 10 minutes, and a total of 600MB in size.
> After import is finished, cached memory is at about 700MB, and it's
> not released.
>
> Here, I try to restart the Apache server. The cached memory is
> SOMETIMES released. If restarting Apache doesn't release the cached
> memory, removing the repository directory with rm -rf repodir does.
> (interesting)
>
> What I did so far in trying to fix the problem:
>
> 1) Played with the Apache prefork settings, didn't work.
> 2) Upgraded Subversion 1.6.2 to 1.6.3, didn't work
> 3) Added SVNPathAuthz and SVNAllowBulkUpdates, didn't work.
> 4) Changed SSLSessionCache from shmcb to shm, didn't work.
> 5) Was forcing SSL connection. Disabled it and used HTTP, didn't work.
>
> These are all changes that affects remote users. None worked.
>
> I finally tried checking out what I imported from Windows, to the same
> repository server to some folder.
>
> I used the svn command:
>
> svn co file:///opt/app/svn/mytest somefolder
>
> Before above command, cached mem was at 700MB (Because of the import
> from Tortoise) When it's running cached mem grew up to 1.4GB, and it
> wasn't released when the operation has finished until I removed the
> checked out folder, using rm -rf somefolder
>
> So it looks like, whatever the problem here is, is not related to
> Apache or mod_dav_svn (web stuff) but maybe libsvn_fs or
> libsvn_fs_base or util.
>
> Has anybody had this problem before? I am open to all suggestions.
>
> Thanks,
> Murat
>
> ------------------------------------------------------
>
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=23
7
> 1596
>
> To unsubscribe from this discussion, e-mail: [users-
> unsubscribe_at_subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2371663
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-16 05:36:17 CEST