<div dir="ltr">On Thu, Jun 6, 2013 at 11:38 AM, Alexander E. Patrakov <span dir="ltr"><<a href="mailto:patrakov@gmail.com" target="_blank">patrakov@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">2013/6/6 Ondřej Surý <<a href="mailto:ondrej@debian.org">ondrej@debian.org</a>>:<br>
<div class="im">> Control: fixed -1 php5/5.5.0~alpha1-1<br>
> Control: tags -1 wheezy<br>
><br>
> Hi Alexander,<br>
><br>
> you might want to pull cron job:<br>
> <a href="http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob;f=debian/php5-common.php5.cron.d;h=8865fddb4c451f38f0d6f1ae722a3082c2eb5f81;hb=refs/heads/debian-experimental" target="_blank">http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob;f=debian/php5-common.php5.cron.d;h=8865fddb4c451f38f0d6f1ae722a3082c2eb5f81;hb=refs/heads/debian-experimental</a><br>
><br>
> and sessionclean script:<br>
> <a href="http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob;f=debian/sessionclean;h=a5f5360d015a4e74199f8c71152ab96f0bd4bb33;hb=refs/heads/debian-experimental" target="_blank">http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob;f=debian/sessionclean;h=a5f5360d015a4e74199f8c71152ab96f0bd4bb33;hb=refs/heads/debian-experimental</a><br>
><br>
> I have already improved the session clean script, but it didn't make it into<br>
> wheezy, because of lack of testers with too many session files.<br>
><br>
> Unfortunatelly we cannot avoid looking at the files, because of #626640.<br>
<br>
</div>I see. The new script does avoid a per-session-file process call, and<br>
that should be much better than the current situation. However, I (as<br>
a person who reviews your code) disagree that the bug has been fixed<br>
completely, because it is still possible that two instances of<br>
sessionclean run in parallel from cron and thus uselessly raise the<br>
load average. Please use a lock file (e.g. with flock -w 0<br>
/run/lock/php5.lck prepended to the original sessionclean invocation)<br>
to avoid that issue. As a bonus, this will generate a cron mail<br>
(without raising LA) if the script does run over its own tail.<br></blockquote><div><br></div><div style>While this might save some cycles if you are cleaning a result of an onetime action, the locking will in fact make the load worse if it is result of an ongoing sessions generation.</div>
<div style><br></div><div style>If you postpone the cron job run by half an hour, the number of sessions will grow by that half an hour.</div><div style><br></div><div style>Let me model that...</div><div style><br></div>
<div style>Let's say:</div><div style>- the number of sessions you can clean in an half an hour is 1.000.000.</div><div style>- the bad guy generates 5.000.000 session files as one shot thing.<br></div><div style>- the normal number of generated sessions per hour is 100.000.</div>
</div><div class="gmail_extra"><br></div><div class="gmail_extra" style>The lock file will cause the files to be cleaned in 3 hours (2.5 hours for the 5 mio + next run for generated 250.000 normal session file which will be generated meanwhile).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra" style>But if it's not onetime thing, let's say:</div><div class="gmail_extra" style>- the number of sessions you can clean in an half an hour is 1.000.000.</div>
<div class="gmail_extra" style>- the number of sessions of generated per hour is 2.100.000</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>The lock file will cause the sessions to never clear because:</div>
<div class="gmail_extra" style>- first run (ETA +0 min) will run for 1+ hour (making two subsequent ETA +30 min and +60 min runs to be stopped)</div><div class="gmail_extra" style>- the number of sessions which will be generated meanwhile is more than 3.150.000</div>
<div class="gmail_extra" style>- the next script (ETA +90 min) will have to clean 3 mio+ session files making it run for ~1.6 hours stopping three subsequent runs</div><div class="gmail_extra" style>- repeat and rinse until you run out of inodes</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>So I actually thinks it's better to suffer from temporary load spikes (with the new script – the old one is crazy, but it took me a while to figure out how to fix it) than to be DoSed by sessions files not cleaning fast enough.</div>
<br clear="all"><div style>O.</div>-- <br>Ondřej Surý <<a href="mailto:ondrej@sury.org" target="_blank">ondrej@sury.org</a>><br>
</div></div>