Re: [PATCH] Bug 3150: do not start useless unlinkd.

 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
Received on Mon Oct 10 2011 - 00:33:07 MDT