It appears the issue was hardware related, everything seems to be working now with nfs
Thanks for your help On 21 November 2011 11:12, Stephen Woodbridge <wood...@swoodbridge.com> wrote: > Travis, > > In the past I have used NFS in a custer and in general the performance was > very bad when compared to SMB. Now this was a few years ago, ie: not using > mapcache, but my experience was that we ran into a few issues with NFS: > > 1. NFS CPU overhead was significantly more > 2. connection recovery was poor if a server was pulled from the cluster and > added back again (ie: recovery after an error condition) > 3. the protocol seems to have a lot more over head > > -Steve W > > On 11/21/2011 9:39 AM, thomas bonfort wrote: >> >> What kind of performance issues? The current locking code only uses >> the presence/absence of a file for it's locking functions, and does >> not rely on flock/fcntl. >> >> -- >> thomas >> >> On Mon, Nov 21, 2011 at 15:16, Travis Kirstine<traviskirst...@gmail.com> >> wrote: >>> >>> Thomas, >>> >>> We have been running into some performance issues mapcache and nfs. >>> We feel the issue may be related to how nfs locks files/directories >>> compared to smb. We are trying a few thing on our end (disable >>> locking / nfs4 etc). Do you have any ideas? >>> >>> Regards >>> >>> On 20 October 2011 12:19, thomas bonfort<thomas.bonf...@gmail.com> >>> wrote: >>>> >>>> So, this discussion inspired me to completely rework the locking >>>> mechanism in mapcache, to stop relying on file locks which have their >>>> quirks on network filesystems. >>>> I have tried using multiple apache instances configured to used a >>>> SMB-mounted lock directory and hammered both instances on unseeded >>>> identical area to force locking, and ended up with absolutely no >>>> duplicate wms requests or failed requests for the clients. >>>> The code is committed in trunk. Thanks for bringing this up, this >>>> allowed me to really simplify the locking code and remove a lot of >>>> unneeded stuff :) >>>> >>>> -- >>>> thomas >>>> >>>> On Thu, Oct 20, 2011 at 17:08, Travis Kirstine<traviskirst...@gmail.com> >>>> wrote: >>>>> >>>>> Andreas and Thomas >>>>> >>>>> Thanks for you responses, I have discussed this with some of our IT >>>>> staff and they had similar solution as Andreas using gfs. Their >>>>> comments are below: >>>>> >>>>> "I suspect this scheme is not reliable over NFS. The problem is the >>>>> directory updates are not synchronized across multiple nodes. I had a >>>>> similar issue with the IMAP E-mail protocol. Our workaround currently >>>>> is to force each user to leverage a single server. >>>>> >>>>> Ref: >>>>> http://wiki.dovecot.org/NFS >>>>> >>>>> Seems like there's some tweaks to disable directory attribute caching >>>>> but this can trigger slower performance. >>>>> Only workaround is to use GFS which I found to have it's own issues. " >>>>> >>>>> Regards >>>>> >>>>> >>>>> >>>>> On 20 October 2011 05:32, Eichner, Andreas - SID-NLKM >>>>> <andreas.eich...@sid.sachsen.de> wrote: >>>>>> >>>>>> We use TileCache.py on two servers with the cache on an OCFS2 on a >>>>>> shared LUN in the SAN. No known issues with that for now. Note: >>>>>> Spurious >>>>>> stale lock files occurred already on a single machine. There seemed to >>>>>> be issues with lots of requests and a very slow upstream server. I >>>>>> used >>>>>> a cron job to delete lock files older than 5 minutes or so. >>>>>> As Thomas noted, if the lock files are created on a shared filesystem >>>>>> and you make sure the filesystem you use is able to lock files >>>>>> properly >>>>>> (read the docs carefully!) there's no reason why it should not work. >>>>>> >>>>> _______________________________________________ >>>>> mapserver-users mailing list >>>>> mapserver-users@lists.osgeo.org >>>>> http://lists.osgeo.org/mailman/listinfo/mapserver-users >>>>> >>>> >>> >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/mapserver-users > > _______________________________________________ > mapserver-users mailing list > mapserver-users@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > _______________________________________________ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
