Opened 4 years ago

Closed 4 years ago

#258 closed defect (fixed)

reproducible memory leak when xcache.size is set too small to process a request

Reported by: cloph Owned by: moo
Priority: major Milestone:
Component: cacher Version: 1.3.0
Keywords: memory leak xcache.size Cc:
Application: PHP Version: 5.3.2(suhosin)
Other Exts: SAPI: FastCGI
Probability: Always Blocked By:
Blocking:

Description

A Virtualbox image to reproduce the memory leak is available here:
http://buildbot-linux-1.documentfoundation.org/VMs/ (downloadsize around 380MB, extracted size ~1.1GB)

When xcache.size is set too a value too small to process a request, memory usage grows limitless, the bigger the difference between assigned and needed memory, the faster the memory usage grows.

Setup to reproduce:

  • Apache with mod_fcgid, only one child process (to ensure all requests go to the same worker for ease of seeing the effect), and the default of 500 requests per process
  • I use silverstripe as php-application to accelerate
  • ab -n 499 http://localhost/ with xcache of 16M (i.e. large enough): no problem, everything is fine
  • set xcache.size to value < 7M (that's approx. what is needed to process the homepage request in the blank setup), for example 4M
  • restart apache or request the homepage once more to spawn a new worker that makes use of the changed setting
  • ab -n 499 http://localhost/ once again, this time memory grows and grows until OOM-killer intervenes,

and it is not a couple of bytes with each request, it easily is more than one MB with each request.

Change History (7)

comment:1 Changed 4 years ago by moo

  • Status changed from new to assigned

comment:2 Changed 4 years ago by moo

access denied. pls fix the file permission on xcache-memleak.ova

comment:3 Changed 4 years ago by cloph

uups, sorry, permissions fixed.

comment:4 Changed 4 years ago by moo

it's not us keyboard and i don't have root access, any tips?

comment:5 Changed 4 years ago by moo

never mind, i have workaround it

comment:6 Changed 4 years ago by cloph

Sorry for not explaining it - ubuntu doesn't have a dedicated root user, everything is done using sudo (just do sudo bash to get a shell with root-permissions if you like), and I prefer to ssh into the VM (so the internal keyboard layout doesn't matter). To change the layout temporarily: "loadkeys us" (as it's a german layout type "loadkezs us" - z and y are switched), to configure permanently use sudo dpkg-reconfigure console-data

comment:7 Changed 4 years ago by moo

  • Resolution set to fixed
  • Status changed from assigned to closed

sure, sudo -s, dpkg-reconfigure console-setup

fixed in [705] for trunk, in [708] in 1.3

Note: See TracTickets for help on using tickets.