Condusiv Technologies Blog

Condusiv Technologies Blog

Blogging @Condusiv

The Condusiv blog shares insight into the issues surrounding system and application performance—and how I/O optimization software is breaking new ground in solving those issues.

MEDITECH Hospital Speeds EHR & MS-SQL with V-locity® I/O Reduction Software

by Brian Morin 28. August 2017 10:06

Community Medical Center (CMC) had one initial requirement – find a FAL remediation solution for their MEDITECH electronic health record (EHR) application to maintain 24/7 availability and avoid downtime. What surprised them the most was the extent of the performance boost from using V-locity I/O reduction software.

“Our doctors and clinicians were losing too much time on basic tasks like waiting on medical images to load, or scanning images, or even just navigating from screen to screen within the application. The easy answer is to buy new server and storage hardware; however, that’s also a very expensive answer. When you’re a small hospital, you need to squeeze every last drop of performance out of your existing infrastructure. Since we don’t have the budget luxury of doing hardware refreshes every three years, we need to get at least five years or more from our storage backend,” said Joe Buckminster, IT Director, Community Medical Center.

Buckminster continued, “We initially purchased V-locity I/O reduction software to meet an availability requirement, but what surprised us the most was how much value it to added to our aging storage infrastructure by offloading a significant amount of I/O traffic. Not only did we get an immediate performance boost for MEDITECH, but we soon realized that we needed to try V-locity on our other Tier-1 applications like NextGen, MS-SQL, MS Exchange, Citrix XenApp, and others.”

Joe identified 35 key virtual servers that ran an assortment of different applications, like NextGen EHR (supported by a MS-SQL database), MS Exchange, Citrix XenApp, GE Centricity Perinatal, and others. In aggregate, V-locity offloaded 43% of all read traffic from storage and 29% of write traffic. With well over half a billion I/Os eliminated from going to storage, the median latency savings meant an aggregate of 157 days of cumulative storage I/O time saved across all the servers over a three-month period. When examining the last 24 hours from CMC’s single heaviest workload on a MS-SQL server, V-locity offloaded 48,272,115 I/O operations from storage (48% of read traffic / 47% of write traffic) – a savings of seven hours in storage I/O time

“There’s no way we would have achieved a 5-year lifecycle on our storage system without V-locity offloading so much I/O traffic from that subsystem. We had no idea how many I/O operations from virtual server to storage were essentially wasted activity due to Windows write inefficiencies chewing up IOPS or hot data that is more effectively served from available DRAM,” said Buckminster.

 

To read the full story on how V-locity I/O reduction software boosted their EHR and MS-SQL performance, read here: http://learn.condusiv.com/rs/246-QKS-770/images/CS-Community-Medical.pdf

Tags:

MEDITECH | V-Locity

FAL Remediation and Improved Performance for MEDITECH

by Gary Quan 28. November 2016 12:11

When someone mentions heavy fragmentation on a Windows NTFS Volume, the first thing that usually comes to mind is performance degradation. While performance degradation is certainly bad, what’s worse is application failure when the application gets this error.

 

Windows Error - "The requested operation could not be completed due to a file system limitation“

 

That is exactly what happens in severely fragmented environments. These are show-stoppers that can stop a business in its tracks until the problem is remediated. We have had users report this issue to us on SQL databases, Exchange server databases, and cases involving MEDITECH EMR systems.

Some refer to this problem as the “FAL Size Issue” and here is why. In the Windows NTFS file system, as files grow in size and complexity (i.e., more and more fragmented data), they can be assigned additional metadata structures. One of these metadata structures is called the File Attribute List (FAL). The FAL structure can point to different types of file attributes, such as security attributes or standard information such as creation and modification dates and, most importantly, the actual data contained within the file. In the extremely fragmented file case, the FAL will keep track of where all the fragmented data is for the file. The FAL actually contains pointers indicating the location of the file data (fragments) on the volume. As more fragments accumulate in a file, more pointers to the fragmented data are required, which in turn increases the size of the FAL. Herein lies the problem: the FAL size has an upper limitation size of 256KB. When that limit is reached, no more pointers can be added, which means NO more data can be added to the data file. And, if it is a folder file, NO more files can be added under that folder file.

If a FAL reaches the size limitation, the only resolution was to bring the volume offline, which can mean bringing the system down, then copying the file to a different location (a different volume is recommended), deleting or renaming the original file, making sure there is sufficient contiguous free space on the original volume, rebooting the system to reset the free space cache, then copying the file back. This is not a quick cycle, and if that file is large in size, this process can take hours to complete, which means the system will remain offline for hours while attempting to resolve.

You would think that the logical solution would be – why not just defragment those files? The problem is that traditional defragmentation utilities can cause the FAL size to grow. While it can decrease the number of pointers, it will not decrease the FAL size. In fact, due to limitations within the file system, traditional methods of defragmenting files cause the FAL size to grow even larger, making the problem worse even though you are attempting to remediate it. This is true with all other defragmenters, including the built-in defragmenter that comes Windows. So what can be done about it?

 

The Solution

Condusiv Technologies has introduced a new technology to address this FAL size issue that is unique only to the latest version of V-locity®  for virtual servers and Diskeeper® for physical servers. This new technology called MediWrite™ contains features to help suppress this issue from occurring in the first place, give sufficient warning if it is or has occurred, plus tools to quickly and efficiently reduce the FAL size. It includes the following:

Unique FAL handling: As indicated above, traditional methods of defragmentation can cause the FAL size to grow even further. MediWrite will detect when files are having FAL size issues and will use a proprietary method of defragmentation that keeps the FAL from growing in size. An industry first!

Unique FAL growth prevention: Along with MediWrite, V-locity and Diskeeper contain another very important, patented technology called IntelliWrite® which automatically prevents new fragmentation from occurring. By preventing fragmentation from occurring, IntelliWrite minimizes any further FAL size growth issues.

Unique Offline FAL Consolidation tools: The above technologies help stop the FAL size from growing any larger, but due to File System restrictions, it cannot shrink or reduce the FAL size online. To do this, Condusiv developed proprietary offline tools that will reduce the FAL-IN-USE size in minutes.  This is extremely helpful for companies that already have a file FAL size issue before installing our software. With these tools, the user can reduce the FAL-IN-USE size back down to 100kb, 50kb, or smaller and feel completely safe from the maximum FAL size limits. The reduction process itself takes less than 5 minutes. This means that the system will only need to be taken offline for minutes which is much better than all the hours needed with the current Windows copy method.

FAL size Alerts: MediWrite will dynamically scan the volumes for any FAL sizes that have reached a certain limit (the default is a conservative 50% of the maximum size) and will create an Alert indicating this has occurred. The Alert will also be recorded in the Windows Event log, plus the user has the option to get notified by email when this occurrence happens.

 

For more information, see our MEDITECH Solution Brief

 

 

 

Tags:

Diskeeper | Disruption, Application Performance, IOPS | General | IntelliMemory | IntelliWrite | MEDITECH | V-Locity

ER Can’t Afford Slow Patient Records

by Brian Morin 1. March 2015 05:36

Slow medical record load times were hurting ER and overall patient care hospital-wide.

Ryan Barker was responsible for overseeing the MEDITECH EHR systems at Hancock Regional. As he put it, “You can imagine how dire the situation can be, particularly in the ER. My users can’t spare precious seconds waiting for data to load and records to save.”

Ryan was considering doing what most admins do when facing a performance issue - throw more hardware at the problem. While considering a forklift upgrade of the SAN that wasn’t in budget, Ryan had heard about what V-locity® I/O reduction software had done to accelerate EHR at other MEDITECH hospitals.

Since V-locity is free to evaluate and tailored specifically for MEDITECH, he figured he had nothing to lose.

Here’s a direct quote from the full case study:

Over the first two weeks of running V-locity on all the MEDITECH VMs, Ryan requested several tests from the Core Team, all reporting impressive results. “The feedback I’m getting from the Team is very positive; they are seeing major improvement,” says Ryan. “Before V-locity, the EDM tracker took seven seconds to load two patients. With V-locity it’s now taking only four seconds to load six patients.” Ryan continues, “Compiling a list of 16 patients took 13 seconds. With V-locity it now takes only five seconds to load 19. That’s a major improvement when you’re talking about a busy day in the ER.”

Hancock Regional was able to put an end to performance issues, defer upgrading their SAN and now looking to deploy V-locity on other I/O intensive applications. In addition, since V-locity comes with the MediWrite™ engine for MEDITECH, the FAL growth issue from severe fragmentation is no longer a risk to downtime. MEDITECH requires all 5x and 6x users to have a FAL remediation plan and recommends V-locity for its real-time and automatic FAL remediation capabilities.

Read the full case study ->

Tags: , ,

MEDITECH | V-Locity

When Speed Matters Most

by Robin Izsak 15. November 2013 05:22

We talk a lot about data around here. Particularly, how to make it perform better, how to make applications respond faster, how to solve some of IT's most formidable challenges around managing increasingly complex data centers.

But nothing compares to the importance of data performance when it comes to patient records and load times in a hospital ER, where every second spent waiting might be a second too long.

I recently spoke with Ryan Barker, Technology Specialist with Hancock Regional Hospital, hoping to get real insight into why speed matters—and I got exactly that. Ryan's users, which consist of ER doctors, nurses—any and all staff who touch the hospital's MEDITECH systems—were complaining of extremely slow load times and the inability to save records. Sometimes in dire situations, like a busy day in the ER.

Read the case study to learn how Hancock Regional used V-locity® VM™ to improve load times from 2 patient records every 7 seconds to 6 records in 4 seconds.

Tags: , , , , ,

MEDITECH

Month List

Calendar

<<  November 2017  >>
MoTuWeThFrSaSu
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

View posts in large calendar