Windows SBS 2003.. need Help!

Hello Everybody,


I have a Windows SBS 2003, which is primarily used as a file server. Shared folders with plain ascii text files are accessed by users to read and write through a DOS 16 bit application. Users also use the shared folder to view "images" in the DOS application.

My challenge is

(a) The Page/Sec is peaking to 100% every 10 seconds and the result is erratic performance - delays experienced by user.

(b) The disk queue also peaks to 70-100% once in 10 seconds.

The server is a Dell PowerEdge 2800 with 4 GB RAM and a Raid 5 System. Approx 30-50 users connect to the Server at a time. The primary is a PDC for the domain. All possible services are stopped on this server and DNS, WINS etc is load balanced to a secondary server.


Any help to improve the performance of the server will be sincerely appreciated. Please let me know if I can offer any more stats to diagonize this further.

Thanks. :



- Santy Balan
san.rely@gmail.com

===============================================

Here are few statistics of the Server :-

TOtal Memory : 4 GIG
Raid 5
C Drive : 12 GB {paging file : 2 - 2 GB}
D Drve : 240 GB {paging file : 8 - 20 GB}

Acting as File Server for shared folders. Accessed by 30-50 users to read/write text files into the shared fodler.

Pages per sec... peaks to 100% about every 10 seconds
Average Disk Queue peaks to 70-80% about every 10 seconds

Process Stats

% of User Time = 5-10%
% of Processor Time = 100%
% of Privileged Time = 100%

Memory

Available Bytes = 100%
Free System Page Table Entries = 100%
Commit Limit = 100%
Page Reads = Spikes in 10 sec upto 100%
Page writes < 5%
Transition faults/sec = spikes in 10 sec upto 100%

Physical Disk

Average Disk Queue = Spikes in 10 sec upto 100%

Paging File

% of paying file usage < 1 % constant

Commit Charge (K)

Total : 2490632
Limit : 14409488
Peak : 2544516

Physical Memory (K)

Total : 4193360
Available : 1663572
System Cache : 1854808

Kernel Memory (K)

Total : 124652
Paged : 73828
NonPaged : 50824

Totals :

Handles : 25707
Threads : 1090
Processes : 74

CPU Usage = 2%

Commit Charge : 2431M/14071M

PF Usage : 2.37 GB

Welcome to firewall.cx, Santy.

The thing that stands out to me first of all is

Shared folders with plain ascii text files are accessed by users to read and write through a DOS 16 bit application

Have you always experienced these performance problems with the server, or did they arise after any changes to the system configuration?

Taking a look at the performance stats:

1. Pages/Sec
Even though this counter appears to be peaking regularly, the other related counters e.g. % of paging file usage < 1 % constant, available System memory are all OK. This KB article sheds some light on why you may be getting these high values. Especially this quote "These high values may instead be caused by the an application sequentially reading a memory mapped file."

A DOS application used by multiple users to access shared files on a Windows server can be affected by locking issues depending on how well the application has been written.

If a dedicated flat-file database format that supports record locking is in use, you may get away it as multiple users would be able to write to same files simultaneously. However, if you have a situation, where users are waiting in line to access (possibly large) ASCII files that have been locked by other users, you can quickly begin to experience bottlenecks and delays. In addition if the ASCII files are very large, and database indexing has not been implemented in the application, they will need to be accessed sequentially which could explain the Pages/Sec figures.

This KB article sheds some light on why you may be getting these high values.

Sorry, but the information presented in the KB article mentioned above does NOT apply to Windows 2003 Small Business Server.

If you had bothered to pay as much attention to the problem as I did, Dead-Neur0ns, you would have realised that it's a problem that could affect both Windows 2000 and 2003 equally. I knew this having used both operating systems regularly. This KB article proves the point. You may need to fire up those neurons!!

I appreciate your obvious willingness to point out errors or shortcomings to posts in the forums, but unless this is backed by up by useful suggestions or indeed any indication that you have made an effort to understand the posts before criticising, it may start to gall.

If you had bothered to pay as much attention to the problem as I did, Dead-Neur0ns, you would have realised that it's a problem that could affect both Windows 2000 and 2003 equally. I knew this having used both operating systems regularly. This KB article proves the point. You may need to fire up those neurons!!

I appreciate your obvious willingness to point out errors or shortcomings to posts in the forums, but unless this is backed by up by useful suggestions or indeed any indication that you have made an effort to understand the posts before criticising, it may start to gall.

If it would have affected 2k3 SBS as you have mentioned I'm sure people at MS have had enough Neur0ns to revise the document or include the product in the listings. The explanation given fails your conclusions.

I'm in noway pointing the short-comings or pointing out errors. I'm just merely stating the obvious. If you are not willing to accept honest criticism, or take into consideration different views than yours, . . . . . . . . . . . . . . . . . . . .

You are wrong in coming to the conclusion, that I've not read the posts. In the future I would suggest you do NOT make any such conclusions about any others. . . . . . . . . . . . . ..

Sigh..... I'll have to go over this again.

If it would have affected 2k3 SBS as you have mentioned I'm sure people at MS have had enough Neur0ns to revise the document or include the product in the listings. The explanation given fails your conclusions.

Ahhh..... such innocent trust in Microsoft's ability and willingness to keep all their KB articles up to date. Makes the tears well up. The second KB I referred to which confirmed that the problem indeed occurred on Windows 2003 as well, contains almost the exact quote I gave from the original "erroneous" KB. i.e. "Instead, these values may be caused by an application that is sequentially reading a memory-mapped file." So the problem DOES occur in Windows 2003.

I'm in noway pointing the short-comings or pointing out errors. I'm just merely stating the obvious. If you are not willing to accept honest criticism, or take into consideration different views than yours, . . . . . . . . . . . . . . . . . . . .

There are many far more knowledgeable posters on this forum than myself: Chris, sahirh, TheBishop, nske, havohej, jwj, tGc and the list goes on. I have however never seen these guys attack a post directly even if it was wrong. And certainly not without providing an alternative.

You are wrong in coming to the conclusion, that I've not read the posts. In the future I would suggest you do NOT make any such conclusions about any others. . . . . . . . . . . . . ..

Sorry if I was wrong in stating that you don't read posts. Since you've stated that you DO read them, I must then come to the conclusion that you don't understand them. Sometimes reading does not always translate to comprehension on the part of the reader. My apologies again. I know from your past posting history that you won't let this lie, but I just wanted to correct your assertion that the information I provided was wrong. Anyway, I hope kbsantosh8, the original poster, lets us know how he's getting on with the problem.