Hi all, I've a BIG problem on a Unix SunOS 4.1.4 running SAMBA (samba-1.9.18p3) in order to export some file systems to WindowsNT client machines. The client are using Visual C/C++ 5.x for compiling files (source are remote, but binary are generated on local disks). The problem is that the CPU time and the IO goes... too UP (I've a load average of 8)!!! I traced the clients (with log level and log file options) and I found that the Visual C/C++ check the files status for EVERY FILES presents in a "Workspace Environment", even if that file isn't opened!!! Here you will find one of the many lines I found into a log file: [...] switch message SMBgetatr (pid 12041) unix_clean_name [./nam/marketseuro/include/mrkutil.h] unix_clean_name [nam/marketseuro/include/mrkutil.h] 05/13/1998 16:10:27 getatr name=nam/marketseuro/include/mrkutil.h mode=0 size=4315 05/13/1998 16:10:27 Transaction 96577 of length 59 [...] Do you have any suggestion??? Please heklp me, because my bosses here want to eliminate that great software which is SAMBA!!!!! Thanks a lots in advance (please replay also to my email address). Bye! P.S. I'm sorry for my bad english!
Giovanni Beani <g.beani@list.it> wrote:> I traced the clients (with log level and log file options) and I found > that > the Visual C/C++ check the files status for EVERY FILES presents in a > "Workspace Environment", even if that file isn't opened!!!I made a longer comment in email, but I want to raise the question here: what are the vendor-specific approaches to dealing with this kind of (mis) behaviour? From first principles, VC++ is doing attr lookups, which cause one directory read and N inode reads, so one wants to do anything one can to increase inode-read speed. From memory, on SunOS 4, I made sure the inode cache was big enough that rereading didn't hurt that much, and found that not having to spill cache in the middle of reading in tons of inodes seemed to increase performance a lot. (I suspect the code got suboptimal when the caches are very close to full, but that's mere opinion) I've not done this at all on Solaris/System V, but have done the equivalent many times of Berkeley derived systems. Can anyone else comment on good techniques, tools, etc.? My reference, by the way was Adrian Cockroft's book, http://www.sun.com/smi/ssoftpress/books/Cockcroft/Cockcroft.html which is also a good reference for Ultrix (:-)) --dave -- David Collier-Brown, | Always do right. This will gratify some people 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain Willowdale, Ontario | davecb@hobbes.ss.org, canada.sun.com M2N 1Y3. 416-223-8968 | http://java.science.yorku.ca/~davecb
Hi David, thanks for your reply.>From memory, you wish to increase the cache buffer headers, memory >used >for caching in general, the something-lookaside buffers and anything >that sounds like directory or inode caching.I did as you suggested (added more cache for inode and directory buffers) and the "load" was much lower... anyway I hope that someone can solve the problem of Visual C/C++ and SAMBA... :) Thanks a lots!!!
Giovanni Beani wrote:> I did as you suggested (added more cache for inode and directory buffers) > and the "load" was much lower... anyway I hope that someone can solve the > problem of Visual C/C++ and SAMBA... :)I think I saw a discussion elsewhere... One of the Real Samba People may be hard at work as we speak (:-)) Alas, it exposes an interesting problem with auto-tuning OSs like VMS and Solaris, which may pessimize themselves on occasion (:-)) --dave -- David Collier-Brown, | Always do right. This will gratify some people 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain Willowdale, Ontario | davecb@hobbes.ss.org, canada.sun.com M2N 1Y3. 416-223-8968 | http://java.science.yorku.ca/~davecb