On Sun, 09 Oct 2011 12:29:03 -0600, Alex Rousskov wrote:
On 10/08/2011 01:25 PM, Henrik Nordström wrote:
fre 2011-10-07 klockan 11:50 +0400 skrev Dmitry Kurochkin:
I did not know that -N was used for anything but testing and
debugging.
Perhaps we should also use diskers in -N mode?
-N is not only a debugging flag. It's used in production in many
setups
where a usable system monitor keeps track of the process. It's "Do
not
daemonize", functionality should otherwise be the same.
(Though, neither Mac OS X nor Debian (by default) use upstart.
Ubuntu
does.)
And fedora uses systemd.
We should add mayUseUnlinkd() method to DiskIOStrategy. But only
UFS
SwapDir would relay answer from it. Other store modules do not
need
unlinkd even if the underlying IO strategy may use it. Do you
agree?
Or perhaps simply start it on first use, similar to how we runtime
add
more helpers of other types when needed?
I like the direction of that approach in general.
If we fork() to start unlinkd, then the fork() becomes the more
expensive the longer we delay it because Squid allocates more and
more
memory, right? If so, waiting until the first unlink seems wrong.
However, if we already fork other helpers that way, perhaps that is
OK.
We do. But the other helpers depend on user scripts etc which can be
expensive, slow, and/or crashing regularly.
unlinkd being simple and under our control does not really seem to need
such dynamic startup. Unless we want to move to the model of N unlinkd
per cache_dir with elastic load handling.
[Forking during reconfigure will be the most expensive, but it is a
rare
exception rather than a rule so we can ignore it.]
If late forking is a problem, perhaps folks suffering from it should
invest in a simple protocol that would allow Controller or even the
Master process to fork new kids on demand?
IMO we need to do that in the long term, sooner done the better. We
discussed a spawner process a while back as an alternative to
vfork()+exec() and fork()+exec(). I tried to convert the ipcCreate to
vfork but failed miserably, maybe someone else with more IPC expertise
could do better.
The core problem being allocation on multi-GB RAM caches in the workers
and lag on fork() it creates. Ensuring that only the workers allocate
themselves a cache_mem will be another good step in this direction.
The spawner could be the coordinator or a separate kid. This will only
be required as a separate process in -N mode I think, though it may be
beneficial always to free up coordinator for passing other messages.
For now, we have a choice of starting a lot of useless unlinkd
processes
(without Dmitry's patch) OR starting only what we need and not
supporting switching to unlinkd during reconfigure (with Dmitry's
patch). I think the latter is better. What do you think?
Note that unlinkd by way of using ipcCreate is linked to send debugging
info to cache.log. So a -k rotate to requires them to be
restarted/forked anyway. I don't think a reconfigure time startup/fork
is going to be any worse than that more common event.
Amos
