Hi, We had symptoms that were identical to yours. We are running Magic OS 8.1SMP and 5.5 SR3.
We installed new HP servers purchased from JJWild running OSAL and Windows 2003 about 6 weeks ago. For 2 weeks everything seemed fine. Then, users in our Retina Center started complaining of slow screens (cursor moving from prompt to prompt very slowly while in Admissions; screens taking many seconds to paint, stuff like that). Then users in our OR booking area started complaining, then other users using ADT as well as other apps. This was mostly related to our "B" machine, so we looked at CPU Usage in the Magic System Monitoring menu on B and saw nothing out of the ordinary - CPU usage of about 12 to 20%. I expected those readings - my brand new dual-processor servers had turned BAR month-end processing from a 15-hour affair to just 2 hours, so the last thing I expected was to be CPU-bound. So for a week we treated this as a network issue and tried everything we could to hunt down the problem, even bringing in an outside network engineer with a sniffer. Couldn't find anything. Finally came back to the server, the B machine, and happened to look at Windows Task Manager CPU Usage and discovered it was running 100% all the time. Checked Meditech and Meditech had 10% usage. After a few days of back and forth with Meditech, we discovered that the problem stemmed from our Micromedex formulary loads into Pharmacy and RXM. Somehow during the loads there was some corruption in the files - the loads would fail, we would delete them and do them again. Apparently, the corrupt parts of the files were not deleted and remained behind constantly attempting to file. Mysteriously, this was invisible to Magic but very apparent to Task Manager, and of course the server. Once the Pharmacy programmers cleared out the corrupt files from the formulary loads, CPU usage in Windows immediately dropped back down to mimic the Magic numbers and there haven't been any more complaints of slowdowns. Have you been loading formulary data recently? If so, that's your culprit. If not, maybe something else along those lines. In any case, you need to get past Meditech's institutional tendency to blame the hardware or the network and get them to look at the apps and jobs on that machine more carefully. Hope this helps. Regards, Don Don Ushak Director of Information Systems The New York Eye and Ear Infirmary 310 East 14th Street New York, NY 10003 (212) 979-4477 Fax (212) 979-4011 [EMAIL PROTECTED] ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Carolyn Schmidt Roberts Sent: Monday, May 07, 2007 4:59 PM To: [email protected] Cc: Joseph Addison Subject: [MEDITECH-L] Looking for Cause of 100% CPU Utilization Posting for the MIS Technical Services Director: We are a Meditech Magic shop currently running OS v8.18 and Magic v5.5.1. Nearly one and a half years ago, we migrated from the HAL to OSAL platform (Dell servers) through JJWild. Recently (past six months) we have encountered an issue where the CPU utilization spikes to 100% causing one of the machines (generally F) to stop processing network and data traffic which requires us to reboot the machine. Additionally, we took v5.6.1 into our test environment around this same time frame. The anomaly generally occurs between the first and fifth of each month, with MAGIC.EXE acquiring 100% of processor time during each incident. Prior to utilization peaking at 100%, the end-users begin complaining of slow system response time (demonstrated by slow refresh rate on screens). In one instance, we replaced the hardware completely; however, the following month ... same thing. Therefore, we believe the problem to be within the Meditech Application itself. Of course, Meditech is blaming hardware and JJWild is stating that the hardware is functioning properly. I have to agree with the latter since the server is not crashing, creating any dumps and is responsive from the console. In addition to the standard Meditech Applications suite, we have added EDM, Data Repository, ..... modules. Is anyone else experiencing a similar problem or have experience with the one identified above? Any provided information would be greatly appreciated. Carolyn Schmidt-Roberts, RD MIS Technical Services Project Manager Suburban Hospital 8600 Old Georgetown Road Bethesda, MD 20814 E-mail: [EMAIL PROTECTED] Phone: (301) 896-3438 Fax: (301) 897-1344
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= To subscribe or unsubscribe to the meditech-l, visit MTUsers.NET. To check the status of the meditech-l, visit MTUsers.NET. For help, email [EMAIL PROTECTED] Visit the MTUsers WikiPedia at MTUsers.NET/mwiki ______________________________________ meditech-l mailing list [email protected] http://mtusers.com/mailman/listinfo/meditech-l
