Problem on dcc 1.3.30 - Continue Not Asking DCC...

Vernon Schryver vjs@calcite.rhyolite.com
Thu Mar 9 20:40:31 UTC 2006


> From: Breno Moiana 


> 1. At least one time, the server stopped responding at the time of the 
> database cleanup. However, it remained that way for about 8 hours. Then 


What was the state of the server for those 8 hours?  The command
`cdcc "host localhost; stats"` should have given some clues.


] >That volume could easily justify a second DCC server.  The DCC client

] We have thought about it, and now that you mentioned it as a possible 
] solution, we will look carefully into it as a solution.
] I know this might be a stupid question, but how can I verify the need 
] for a secondary server? I mean, the CPU is constantly idle, and nearly 
] all my memory is being used for cache... where is the bottleneck? 

My best guess is that Linux is doing bad things, but that's only a guess.
It would be good to check the state of the system and dccd when dccd
is not answering.  Besides `cdcc stats`, I would check the system
with ps, vmstat, top, and so forth.



] all my memory is being used for cache... where is the bottleneck? Would 
] a second server help me even if I have a lot of unused hardware on this 
] server already?

The second server would be need only when the first server is not answering.


] An option I can think of is to install VMWare on this machine, and make 
] two servers in this hardware. Should this work ?

I doubt that would be a good thing.  Can dccd even run in Linux
over VMWare?  If all of RAM is tied up by one dccd instance, running
a second instance would not help.  If it could help, then it would be
better to just run two DCC servers, one on port 6277 and the other on
some other port.   I don't recommend doing that, although for various
reasons I run 2 and sometimes 3 copies of dccd on my personal FreeBSD box.


] 127.0.0.1,-                 RTT-1000 ms  anon
] # *127.0.0.1,-                                               OiComBR ID 1004
] #     100% of 32 requests ok   51.57-1000 ms RTT        50 ms queue wait

As I said, 50 ms is not good.  However, that `cdcc info` output says
that the server is not really that slow.  Your client does not have a
valid DCC client-ID and password but is instead anonymous.  Your
server is imposing the default anonymous client delay of 50 ms.  You
should assign a client-ID such as 32768 in /var/dcc/ids on the server,
and then tell your DCC clients to use it with the command

    cdcc "add  127.0.0.1   RTT-1000 ms   32768  secret"

where "secret" is password for 32768 in /var/dcc/ids.

After switching to a non-anonymous client-ID, you will only want to
send mail with the results of `cdcc info` run as an ordinary user and
not root.  When run as root, `cdcc info` and `cdcc rtt` show secret
passwords.



] I don't think so... right now, the database is at 1.35GB, and it is not 

I hope you are using `cdcc stats` to measure the size of the database.
Many UNIX varients do not do the right thing to dates or even sizes 
in the inode of files changed with mmap().


] About the "continue not asking" mechanism, I noticed that sometimes the 
] system just gets out of its idleness and gets back to a responsive 
] status, without any interference. 

When the "continue not asking" mechanism counts down, the client tries
again.  If things fail again, the count is doubled (unless it is already
at the maximum) and resumes counting down.

]                                   Another thing is that even when I 
] stop/start the service, it keeps counting from when it was. Can I reset 
] the counter? Some command to tell the server: "Hey, try it now, let's 
] see if what I did worked for you".

The counting is done in the DCC client, not the server.   THe server 
might be down entirely and so cannot be trusted to maintain the count.
I think many times `cdcc rtt` will reset the client.



} What is that 2016 MByte window? Can it be enhanced? Should it? I seem to 
} have plenty of memory:

The "window" is the total size of the mmap() pool of buffers mapped
onto the file.
Perhaps 2 GByte is too large for your version or installation of Linux.  
Do you have plenty of swap space?

It might be interesting to try rebuilding with a smaller "window" with

   /var/dcc/libexec/updatedcc -c --with-max-db-mem=1500

If that does not help, remember to restore default by
   
   /var/dcc/libexec/updatedcc -c --without-max-db-mem


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.