Database rebuild - still slow on new hardware

[spikespiegal]

This one has be baffled. I have client that runs 24/7 retail, and their point of sale software database requires a re-build once a week or performance suffers. While their POS software is current, it runs on an ancient version of Sybase that's about 10 years old.

They were previously running their back-end server on a P3 800. I upgraded the box to a dual core Opteron 2.4, but I kept all software versions, including the OS the same.

Obviously the move to the modern processor drastically improved normal transaction times. But hasn't improved much is the time it takes to run the database rebuild. Moving to the newer processor maybe knocked off 15% of the rebuild time, but that doesn't make sense. Given the POS system has to be taken off line for a dbase rebuild it's critical I reduce this time ASAP.

I have two theories; first one is the version of Sysbase has enough 16-bit code in it to make any move to better hardware irrelevant. Second theory is that many small commercial POS systems contain what I call 'throttle code' to prevent a single process from taking too many resources so they can brag to their mom and pop clients that it runs fine on their ancient pentium 3's and Windows 98.


Any possible insight suggested.

 

[imported_KuJaX]

Alternative may be to look at a new pos software/database?

 

[EagleKeeper]

Can the POS S/W be decoupled from the database?

 

[KB]

Did you improve the Hard Disk speed? I would move to at least 10,000 rpm SATA.

 

[spyordie007]

Have you done any performance monitoring to try and identify the bottleneck (assuming it's hardware related)? It could be beneficial to review the subsystems side-by-side to see what takes the biggest hit (CPU, memory, disk, etc.)

I also like the idea of separating the application from the database. Do you have the ability to run the required queries directly against the database without the application as a front end?