Re: How to Troubleshoot Poor Terminal Server Performance and Reliablity
- From: "dln" <dnadon_nospm@xxxxxxxxxxx>
- Date: Mon, 24 Oct 2005 10:31:09 -0500
After analyzing the latest crashdump file, it looks like the service or
driver that's causing the crash is tied to the symevent.sys file - which
apparently points to the Symantec AV services running on the box. I'll
remove the service on the next maintenance cycle and see if it addresses any
of my issues.
"dln" <dnadon_nospm@xxxxxxxxxxx> wrote in message
news:uRNiIXC2FHA.3864@xxxxxxxxxxxxxxxxxxxxxxx
> Of course now that I've sent off this message, I noticed something that I
> hadn't before. Right now, nobody is logged onto the system other than the
> domain Admin via an RDP connection. There are however, several processes
> running from users that are not logged into the system. I guess it gives
> me something else to look at.
>
> "dln" <dnadon_nospm@xxxxxxxxxxx> wrote in message
> news:u1d7xTC2FHA.3120@xxxxxxxxxxxxxxxxxxxxxxx
>> Thanks for the quick response. The server has been in production for
>> just over four months. It was working fine up until about two months ago
>> when, at that point, the problems were intermittent and not that common.
>> They've gotten worse over time (and I'm sure the umpteen number of
>> crashes haven't helped, either). Upon looking back at when the systems
>> were patched and the timeline of trouble tickets submitted against the
>> system, there doesn't appear to be any correlation. We've made sure that
>> we're up to date with all the drivers, firmware, BIOS updates, etc... for
>> the system and they've neither helped nor magnified the problem.
>>
>> We keep the system locked down so that anybody that logs into it does so
>> as a member of the local users group and therefore is limited in the type
>> of changes they can make on the system. Really the only thing that they
>> can really do is add data to the system drives. Coincidentally, as more
>> data has been dumped on the fibre channel drive, the more common the
>> problems became (we started at ~200GB and we're now up to ~800GB). This
>> however strikes me as a red herring since I figure there are quite a few
>> datacenters out there that have much larger disk arrays attached to their
>> systems. I suppose my next step might be to attach WinDBG up to the last
>> crash dump file and see if I can at least tie the crashes to a specific
>> driver or service.
>>
>> Thanks again.
>>
>> "Vera Noest [MVP]" <vera.noest@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
>> message news:Xns96F8F0EA6DEACveranoesthemutforsse@xxxxxxxxxxxxxxxx
>>>I would not treat this as a "normal" performance problem, it sounds
>>> as if something much more serious is wrong.
>>> Is there anything in the EventLog on the server?
>>> Have you searched Dells download site and updated BIOS, all drivers
>>> and firmware to the latest versions?
>>> How long has this server been in production? Did it ever function
>>> normally? If so, when did the problem start? In connection to which
>>> change?
>>>
>>> _________________________________________________________
>>> Vera Noest
>>> MCSE, CCEA, Microsoft MVP - Terminal Server
>>> TS troubleshooting: http://ts.veranoest.net
>>> ___ please respond in newsgroup, NOT by private email ___
>>>
>>> "dln" <dnadon_nospm@xxxxxxxxxxx> wrote on 23 okt 2005 in
>>> microsoft.public.windows.terminal_services:
>>>
>>>> Hello all,
>>>>
>>>> I'm having problems with one of our site's W2K3 Terminal Servers
>>>> and I'm wondering if someone could perhaps give me some pointers
>>>> on how I could best troubleshoot the issues. The server itself
>>>> is a Dell PowerEdge 1750 with dual Xeon processors running at
>>>> 3.06GHz and it has 2GB of memory. It has a 2TB fibre channel
>>>> disk array attached to it via a QLogic QLA2300 controller. The
>>>> system is used by staff members for accessing MS Office
>>>> applications (Outlook, Word, Visio, Project, etc...), Adobe
>>>> Acrobat and it exports a portion of the 2TB file system as an
>>>> NSF share via MS Services For Unix 3.5.
>>>>
>>>> The problems that I'm having with the system vary with the most
>>>> important being that I can't seem to back up the fibre channel
>>>> disk. Right now, approximately 300GB is in use and I've
>>>> attempted to use NTBackup to back this up, but all NTBackup ever
>>>> does is sit in the background using CPU cycles. After 18 hours
>>>> of the backup process doing nothing, I finally terminate the
>>>> process. I've also tried to use one of the UNIX systems that
>>>> mount the NFS export to tar up the directories in question (and
>>>> I know this really isn't the best idea, but it's an act borne
>>>> out of desperation). However, once the tar file starts
>>>> approaching the 200GB range, the Windows server crashes. I've
>>>> yet to be able to determine whether the crash is due to SFU or
>>>> the fibre channel card driver, but I'm pretty sure it's one or
>>>> the other.
>>>>
>>>> In addition to the backup problem, the reliability and
>>>> performance of the applications on the system is (as one of my
>>>> users put it) abysmal. Several of the Office applications can
>>>> take minutes to start and although once they are up they don't
>>>> crash, closing the apps can require killing the process through
>>>> Task Manager.
>>>>
>>>> Logging in and out of a Terminal Server session can many times
>>>> create problems too. During the login process, the server
>>>> occasionally fails to find the user's TS profile but if the user
>>>> logs out and back in, it gets found on the next pass. Logging
>>>> out of a TS session can take upwards of 15 minutes. During this
>>>> time, the RDP client session simply displays the "Logging out
>>>> and saving your settings" screen. I've tried profiling the
>>>> logout process via Performance Monitor, but there's nothing that
>>>> shows up as being the culprit for the long log-out.
>>>>
>>>> Patching the system is troublesome in that many times the
>>>> msiexec just hangs, forcing a reboot of the system. Rebooting
>>>> the system doesn't work about 90% of the time in that the system
>>>> hangs on shutdown (mouse still seems to respond, but nothing is
>>>> happening) and in the end, I need to power off the system.
>>>>
>>>> We have several other TS in the organization, but none of them
>>>> show the type of behavior of this one system. The only two
>>>> differences between the other systems and this one is that the
>>>> system giving us problems is using SFU 3.5 and it has the
>>>> attached disk array. At this point, I would like to move the
>>>> array off of Windows and onto a Linux box (thereby taking both
>>>> the array and SFU out of the mix) but without me being able to
>>>> back up the file system, this isn't an option. Can anybody give
>>>> me some options of how I might be able to address the issues I'm
>>>> having?
>>>>
>>>> Thanks,
>>>>
>>>> dln
>>
>>
>
>
.
- Follow-Ups:
- Re: How to Troubleshoot Poor Terminal Server Performance and Reliablity
- From: Vera Noest [MVP]
- Re: How to Troubleshoot Poor Terminal Server Performance and Reliablity
- References:
- How to Troubleshoot Poor Terminal Server Performance and Reliablity
- From: dln
- Re: How to Troubleshoot Poor Terminal Server Performance and Reliablity
- From: Vera Noest [MVP]
- Re: How to Troubleshoot Poor Terminal Server Performance and Reliablity
- From: dln
- Re: How to Troubleshoot Poor Terminal Server Performance and Reliablity
- From: dln
- How to Troubleshoot Poor Terminal Server Performance and Reliablity
- Prev by Date: Re: TS always in install mode
- Next by Date: Re: Local Resources
- Previous by thread: Re: How to Troubleshoot Poor Terminal Server Performance and Reliablity
- Next by thread: Re: How to Troubleshoot Poor Terminal Server Performance and Reliablity
- Index(es):
Relevant Pages
|
