> From: Gary Mills <[email protected]>
> > The servers do have sufficient memory. I'll do some testing to see if > > `-H/var/run/dcc' solves the problem. > > Well, that was dramatic. On one of my production DCC servers, the I/O > bandwidth dropped from 50% utilized to zero. For your amusement, Their lack of mmap(MAP_NOSYNC) make Linux and Solaris much slower DCC servers than FreeBSD or NetBSD. The default hyperactive Solaris mmap() page flushing that required `dccd -F` makes Solaris even worse than Linux. A RAM file system for dcc_db.hash mostly fixes both Linux and Solaris for dccd. Judging from their graphs on the server status web page, I suspect only one of the two umanitoba.ca servers is running a 64-bit dccd, and that the larger pointers let dccd take advantage of the more than 4 GByte of RAM on the system. That forced the dccd buffer page or chunk size to be twice as large or even larger. The active hash table entries for the same number of flooded or local transactions are spread among twice as many bytes. Either or both effects caused twice as many bytes to be flushed to the dcc_db.hash file. The graphs for server names in bold on the server status page are visible to other operators. Follow the link in the first column. Operators who didn't see the same note in the DCC-servers mailing list and who are willing to let other operators see the graphs of their servers can contact me. Also contact me if your user name and password for the server status web page have been lost. Vernon Schryver [email protected] _______________________________________________ DCC mailing list [email protected] http://www.rhyolite.com/mailman/listinfo/dcc
