Koozali.org: home of the SME Server
Legacy Forums => Experienced User Forum => Topic started by: Kelvin on September 10, 2003, 05:11:18 AM
-
Hi All,
I'm hoping someone may have experienced this and have come up with a fix for this before. Sorry, this is a long post as I'm trying to be as complete as possible.
I have one site that runs a custom DOS application. After continual problems with application performance on their current SME 5.6U4 server (an Athlon 1900XP with lots and lots of RAM), I put in a separate SME server (this time an Athlon 2400XP with lots of RAM again) specifically to be a file server for this application. All PCs and servers are using 10/100MB cards and on 10/100MB switches. However, the same issues persists. Here's a brief desription of what's happening.
1. The admin side of the office has about 10 - 15 users doing standard office apps - ie. Word, Excel, MYOB - that sort of stuff. The data entry side has up to 30 users running this custom DOS application.
2. During the course of the day, when we were only running the one SME server, everything starts fine in the morning (with admin (ADM) running between 8 and 15 people) and the data entry (DE) about 5 to 10 people. Towards the afternoon and early evening when DE reaches about 15 to 20 people, file access from the server starts to slow down visibly. Files that used to load within a second or two starts to take 4 or 5 seconds. By the evening, when DE has over 20 people in it and most of ADM have started to leave or have left, leaving mostly only DE online, the server starts to crawl. The DOS app which DE runs retrieves a number from a file located on an ibay share. One designated Windows PC acts as allocator and updates that file with new numbers for the other workstations to pickup. When the application starts to slow down, everyone is affected, including the few remaining ADM users who are just using office documents. The number allocation and pickup should happen almost instantly and at most wait only a couple of seconds. When then slowdown begins, it can take between 3 to 5 minutes for a number to be allocated.
3. After introducing a 2nd SME server just to serve the DE group, the ADM users no longer have problems with accessing files from the original SME server even when the DE group again have the same slowdown problem on the new SME server. Somehow, the DOS app is causing something (samba perhaps ?) to slow to a crawl, enough to cause major issues with all connected samba users. The problem gets proportionally worse as the number of users increase.
The problem is the application used to be served by an old Novell server that was retired as it was getting really old (Pentium 233MMX with 64MB RAM). The DOS application runs perfectly and lightning fast even from such a low powered server. I am guessing perhaps it is a file locking issue or something.
I would like to try Samba 2.2.8xx and see if it might fix the problem. Anyone has any suggestions as to a probable cause / fix to the problem above ? Also, anyone has instructions for installing Samba 2.2.8xx ? It only comes as one large rpm and not as samba-client, samba-common, etc (probably integrated into the one large rpm). If you try to rpm -Uvh (after fixing the cups dependency) you get a warning about Update4 needing samba-common, etc. Is it safe or correct to use the --nodeps switch to install it ?
Thanks In Advance !
Kelvin
-
Samba has known idiosyncrasies with database file & file locking - I have upgraded several servers to 2.2.8 with limited sucess (MYOB/Access files are my main drama).
Log onto contribs.org and download the advanced workgroup contrib by James Price. We have been working together (he is supplying most of the blood, sweat, & tears with me adding ideas, testing, some docs and moral support:-)) to extend the scope of his original app to allow control over a lot more of the Samba features including tuning parameters.
You can also use it to turn on more extensive logging for diagnostic purposes.
HTH
-
Samba is great. But it's a reverse-engineering job of an already fairly squirrelly system. Most of the problems do seem to be in sharing / locking / etc.
My advice?
1. If that Netware license is still around seriously consider going back to it. It's not flashy, it's not trendy, but damn it just WORKS. Kinda like the old HP LaserJets it don't die but keeps chugging out the services.
2. Was the DB designed to work with Netware? Back in the day lots of client/server applications were specifically tuned to take best advantage of Novell's network clients. I remember setting all sorts of opportunistic locking flags and such. If so, again, consider going back or migrating the DB to something more modern.
3. Get a good book on Samba, also hit up some Samba specialty sites and search for other reports of your problem. You might have to dive deep to get the settings right for your needs. Track down the install documentation for the DB and see if it notes any special needs that could be applied to today's situation.
4. Look into the settings on the clients. There are lots of options one can use regarding how DOS talks over a network, how it treats files, different types of locks, caching, etc. Those are true for DOS running on it's own and also for DOS running inside something else. Experiment with those a bit (but keep a daily backup of the DB and check regularly for corruption!)
Good luck. Again, mebbe going back to Netware for this could be the short-term solution.
-
Thanks for the replies Graeme and Maggard.
Going back to Netware was certainly on the cards. One that we are trying to avoid if at all possible.
The DOS app is a custom written application, not an off the shelf one. The programmer is less than communicative (or helpful in trying to track the issue down --> "We have no problem on a Windows 2000 Server" he says). The application is not tied to Netware in anyway - neither protocol nor BTrieve dependent. It uses purely file services. The file locking / multiuser access method is the programmer's own design. I'm not about to go digging through his source to get this working if he is not helpful to begin with. Given the number of man hours needed to track something like this down (plus those already spent on it), it might have been cheaper to skip SME altogether and put in W2K to begin with. Problem was, when evaluating an SME server for the role, there was no way to simulate a full load of people. Smaller groups of access appeared to be fine, 1 or 2 second delays were acceptable.
However, should we find that SME's problems with this app is not solvable or cannot be tracked down, the preferred solution is actually to move to Windows 2000 / 2003 server and pay Uncle Bill his dues and not move backwards to Novell.
Cheers !
Kelvin
-
Kelvin wrote:
>
> Thanks for the replies Graeme and Maggard.
Most welcome.
> Going back to Netware was certainly on the cards. One that we
> are trying to avoid if at all possible.
Just out of curiosity - why? Or rather - why not?
If it's paid for, worked, had no outstanding issues other then being "old", I don't understand. True it's probably no longer supported but then e-smith isn't either. Drivers can't be the issue, everything still ships with Netware drivers. Skilled administrators, well an old working Netware is certianly easier then tuning Samba.
All your call, and really one of my business, agan just curious.
-
Hi Maggard,
Actually, because it's Netware 3.2, there are issues with running it on newer hardware - we came across a number of these issues when moving the netware server from an old 486 to the Pentium system a few years back - we might be able to sort of work around them but it will not be ideal because it will be even worse than running SME - there's very little else you can do on the server except be a file server.
At least if they put in the W2K server, there's any number of things they can run on the server itself plus it is a whole lot easier to self manage than either Novell or SME.
Kelvin
-
Thanks for the answer.
I did a bit of spelunking, looks like locking is indeed where you'll run into problems. a good explanation was at:
>http://www.linuxquestions.org/questions/archive/3/2002/12/3/38531
That's a bit dated (9 months) but points up the problem. If your programmer was doing something particularly 'clever' or non-standard then it looks like it could get iffy.
E-smith makes a great server. Samba is a decent tool too, impressive it works as well as it does. However in this case it looks like yeah, you might do better saving yourself the effort and going MS.
I would still consider keeping the e-smith around tho'. Dedicating the Win2k server to the DB and using e-smith for other groupware services (other files, email, etc.) would make (IMHO) tuning better, backups easier, keep all of the eggs out of one basket.
Good luck.
ps A few years ago I had to restore an old Netware server (2.15c), did it under Virtual PC. While not the most elegant of solutions it worked fine. Creepy, but fine. Creepier was then putting it on an Apple Powerbook (soooo wrong!) and watching a bunch of clients connect to it. Later as a goof we got Win98 & NT4 all running at the same time on the Powerbook.
Just throwing that out but I wouldn't do it for production either. Could use it to freak the programmer though.
-
Hi - this is for Graeme Flaming... We also are having locking issues with MYOB running on our SME server where it seems to run at snail's pace. Can you give more specific advice on what you have tried/what has given a performance improvement with MYOB.