Hi all, Recently we implemented the use of a BerkeleyDB-based RewriteMap under Apache 1.3.x for our production environment of 6 webservers. The .db and .pag files resided on an NFS share served by a commercial NAS device and were only read by the webservers, not written; updates to the BDB were done on a separate utility machine. We experienced a lot of problems with this setup; after an indeterminate period of time, the httpd processes would become unresponsive and appear in the "nfs_wait" state while the system load skyrocketed (probably as a result of the NFS shares being mounted "soft"). After changing all servers' NFS options to "hard" we were able to kill the unresponsive httpd's but Apache would fail to restart unless the machine was rebooted. (An strace indicated the the machine was getting stuck on a stat64() of the .pag file.) I have a couple of questions for the list: 1) Is it bad to put BDB RewriteMaps on an NFS server? Is anyone else doing it without problems? 2) Is it true that some versions of BerkeleyDB don't have "read-only" semantics, and could this be causing the problem? 3) Is the problem here related to incorrect POSIX file-locking semantics on the NFS server as some of my colleagues at work have implied? This NFS server hardware is fairly recent (purchased within the last 3 years) so I'd be very surprised if this were the case. 4) Could it be possible that this is just tickling a bug in the Linux kernel? We're running SuSE Linux Enterprise Server 9. Any thoughts or insights would be welcome. - Julian -- -- Julian C. Dunn, P.Eng. <Julian_Dunn@xxxxxx> -- Platform Administrator * CBC.ca Production & Operations -- Office: 2C310-J * Tel.: (416) 205-3311 x6988 --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|