Stefan Sperling writes:
> Should we raise an issue with mod_dav developers? (gstein?)
I suspect any mod_dav fixes are probably going to be written by us. I
think the fix might be to have dav_validate_request() identify the
conditions that mean dav_validate_walker() will always return NULL,
i.e.
On Mon, Dec 8, 2014 at 8:42 PM, Stefan Sperling wrote:
> On Mon, Dec 08, 2014 at 08:30:31PM +0100, Stefan Fuhrmann
> > > > Finally, to minimize cache usage, make sure to disable fulltext
> > > > caching as well (enabled by default in 1.9) and set the cache
> > > > size to *1*, not 0. The latter w
On Mon, Dec 08, 2014 at 09:23:10PM +, Philip Martin wrote:
> Philip Martin writes:
>
> > I think this extra walk is pointless most of the time and is just making
> > our nominally O(1) copy operation slower. Locks on the copy source do
> > not prevent a copy.
>
> Oops! I meant to write "Loc
Philip Martin writes:
> My pool-debug build uses my own httpd build from 2.2.x@1562432 while my
> normal build used the system httpd, Debian's 2.2.22-13+deb7u3. It looks
> like some change to mod_dav has added an extra walk over the copy source
> in the pool-debug build and the absence of this w
Philip Martin writes:
> I think this extra walk is pointless most of the time and is just making
> our nominally O(1) copy operation slower. Locks on the copy source do
> not prevent a copy.
Oops! I meant to write "Locks on the copy source held by somebody else
do not prevent a copy".
--
Phil
Philip Martin writes:
> I'm still trying to determine why this
> extra walk is present, perhaps the new version is doing an unnecessary
> walk or perhaps the old version has an unfixed bug.
Debian's httpd doesn't have r1497441 which introduced the extra walk for
copies, apparently to fix PR 5461
Philip Martin writes:
> The problem is easy to reproduce with pool debugging enabled and the
> patch does reduce memory use, but with a normal build I don't see the
> excessive memory in the first place.
My pool-debug build uses my own httpd build from 2.2.x@1562432 while my
normal build used th
On Mon, Dec 08, 2014 at 08:30:31PM +0100, Stefan Fuhrmann wrote:
> Hm. 381 MB are massive, then. Maybe I can find reproduce it
> and help tracking it down with a modified APR.
Yes, we should be able to manage with much less.
Though perhaps what's left is in in mod_dav rather than mod_dav_svn.
> >
On Mon, Dec 08, 2014 at 07:19:57PM +, Philip Martin wrote:
> I have been looking at the proposed 1.8/1.7 backport for issue 4531.
> The problem is easy to reproduce with pool debugging enabled and the
> patch does reduce memory use, but with a normal build I don't see the
> excessive memory in
On Mon, Dec 8, 2014 at 7:46 PM, Stefan Sperling wrote:
> On Mon, Dec 08, 2014 at 06:42:38PM +0100, Stefan Fuhrmann wrote:
> > IOW, pool debugging is nice for tracing allocations but if you
> > want to measure memory consumption on the OS side, turn
> > pool debugging off.
>
> All measurements I m
Stefan Sperling writes:
> Which option are you referring? The SVNInMemoryCacheSize option?
> The doc for that option says "0 deactivates the cache". Is this an error?
http://subversion.apache.org/docs/release-notes/1.7.html#data-caches
"Please note that a cache size of 0 will deactivate the new
Stefan Fuhrmann writes:
> This post has been prompted by issue 4531 and r1643834
> (http://subversion.tigris.org/issues/show_bug.cgi?id=4531
> http://svn.apache.org/viewvc?view=revision&revision=r1643834).
> IOW, pool debugging is nice for tracing allocations but if you
> want to measure memory
On Mon, Dec 08, 2014 at 06:42:38PM +0100, Stefan Fuhrmann wrote:
> IOW, pool debugging is nice for tracing allocations but if you
> want to measure memory consumption on the OS side, turn
> pool debugging off.
All measurements I mentioned in the issue were done with pool debugging
disabled. Measur
This post has been prompted by issue 4531 and r1643834
(http://subversion.tigris.org/issues/show_bug.cgi?id=4531
http://svn.apache.org/viewvc?view=revision&revision=r1643834).
We had a somewhat similar issue with log -v & friends in
summer this year. Now, I dug into the APR code and this
what I fo
14 matches
Mail list logo
