On 02/09/2014 03:14 AM, stelgenkamp wrote:[color=blue]
Dear Ab,
Yes this maybe related to the application.
However this is the companies main program, and this uses the sybase
database.
So changing the database is out of the question.[/color]
I’m not suggesting changing the database system, just verifying that this
is part of that program and not the overall environment. Until we know
more about what is happening knowing if it is normal or not is tricky.
[color=blue]
The VM only runs this program and database, it does nothing else.
I have assigned 4 cores to the VM, but it does not seem to matter in
speed.
Also assigned 4 Gb of memory, to try and speed up everything.
The VM is running on a 80 Gb raw image file.[/color]
Do you think this is a problem with processing power for some reason? Are
you seeing contention on the virtual processors during these operations?
My original response, about testing other databases and asking what else
the database was doing at the time, was not meant to be limited to
processing. Your initial complaint is about I/O, and usually I/O becomes
slowed significantly by other I/O (for example, if your database is
running normally and doing normal reads and writes at the same time you
are trying to have it create a backup) so I would probably focus more on
the disk system than processor and RAM unless you have evidence proving
the problem is due to a limitation of processor and/or RAM.
[color=blue]
So what is your opinion on this setup ? any recommandations ?[/color]
Same as before. Test other systems to verify this is (or is not) related
to the application. Post the actual commands being used that show the
slowness.
Other ideas: try swapping out the OS. windows isn’t known for
high-performance (see the top 500 supercomputer list, for example) and
chances are that a DomU running Linux can perform better, assuming this is
at all related to the OS itself (I recall that Sybase is cross-platform…
correct me if wrong). I wouldn’t try this first though, since the
evidence still seems to point at limitations on the application side.
[color=blue]
Any other ideas what could be causing the delay in database speed ?[/color]
Just what is mentioned above. Find the bottleneck based on evidence and
then test things that will help you verify or rule out hypotheses. This
is the reason for the suggestion about trying another DB for testing, or
stopping all other database activity when doing the backup, as well as
requesting the commands used. For example, if the commands used are
simply copying database file within the operating system (meaning the
database itself is not involved) then the database itself should not
matter and now you have an OS issue. On the other hand, if the commands
are within Sybase and instruct the system to, while doing production work
as well, create a backup of the database then you are now adding work o an
application that may already be I/O constrained, or to a system that may
already be I/O constrained due to the application doing reads/writes to
the same database (and system) that is now going to be used for creating
the backup.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…