Please see link for full rant/problem explaination. I was contacted and it was suggested that no answer could be found for this without a tcpdump and a strace of the offending program. But there are some difficulties in complying. 1 is this server is a FreeBSD server 5.1pl13 and strace does not run on this branch of FreeBSD because Strace is predominantly a Linux debugging tool. From reading the README.freebsd in Strace it appears to work marginally in 4.x branch. The other problem is that the network is hubbed on switches. So the server would have to be doing the tcpdump while it was trying to serve files. As you can see I'm providing pretty much the default config file since this is what SWAT puts together initially. (Note: Any complaints about special flags not being used or network settings not found in this conf file will be met with some predjudice since we're now at V3.0 of Samba an if it can't configure itself or aid in proper configuring to a nearly layman's level. Then something is seriously wrong. ) If there is a special debug flag that needs to be set so you can get the info you need please let me know. The documentatin for debug and debug logging is pretty sparse. # Samba config file created using SWAT # from titan.shires.org (207.65.58.195) # Date: 2003/08/06 06:07:51 # Global parameters [global] workgroup = GENERAL netbios name = BFS interfaces = fxp0 security = SHARE encrypt passwords = Yes guest account = mare hosts allow = 207.xx.xx.xx/255.255.255.240 65.xxx.xxx.xxx./255.255.255.192 [fileserv] path = /ccd1/fileserv read only = No guest ok = Yes (IP addresses xx'd for security )
waiting on strace-like output and raw network capture file.
some notes from the samba ml: ----------------------------- Ertan Kucukoglu wrote: |> We continually work on improving performance |> as we can. What specifically are you referring |> to? | | | I referred to Davon Shire's e-mail dated 09 March | 2004 18:59. | | In the mean time, I remember some programs indicate | performance gain by percentage. I do not remember any | name in my mind. But, IMHO similiar approach maybe | good for samba. We actually gained significant performance improvements with the "TDB scalability issue surrounding the TDB_CLEAR_IF_FIRST flag". This will be mainly seen by larger installations (maybe >100 concurrent connections). I missed Davon's mail the first time (the danger of the signal-to-noise ration on this list sometimes). Here's the gist: | SMB transfer from Client1 to Client2 6.0 MB/s both ways. | | FTP transfers: average 8.7 MB/s from Server to Client1. | 5.7 MB/s from client1 to Server. | FTP transfers: average 9.0 MB/s from Server to Client2. | 6.0 MB/s from Client2 to Server. | ( Yes there is some noted asymetry here but the data flow | over the network is smooth, there are no pauses or breaks | in the data transmission. ) | | Samba Transfers: Average 6.0 MB/s from Client1/2 to | Server. 1.75 MB/s from server to Client1/2. (does not | matter which machine, they both produce almost identical | network behavior.) | | ( The reason the average from server to clients is so | low is due to unexplainable lulls in transmission from | the server to the client. Peaks in the transfer near | 6.0 MB at times. ) ... | I have as previously stated tweaked, recompiled, adjusted. | read dozens of performance tips for getting the most out | of Samba and it's just not happening. I've adjusted read | size, Sendbuf and Recvbuf values, MTU, MSS, lowday, no | delay blah blah blah. I've watched for collisions. | (None) I've watched for NACKS ACKS and the last episode | of The Tick. But I can't get much better than I already | have out of these machines. | | If I'm missing something obvious please tell me. But | if it's obvious then why isn't it working straight out | of the Install? If I were going to start trouble shooting this I would need to see a network trace to see what the packet previous to the stall was. We would also need to know what the smbd process was doing during the stall using strace (i.e. was it waiting for a repsonse such as an oplock break or was it looking for some data in a tdb, etc...). And as a final note, bugs will get lost on this list. The \preferred method of tracking defects is to log a reoprt at https://bugzilla.samba.org/. So Devon, if you would be will to open a bug report and provide me with the requested information, I'll try to burn some cycles on it.
guess it wasn't that important. No response from reporter since March. CLosing.