well, thanks for the hints regarding transaction-serialization
performance but, if you read my very first e-mail, I didn't mention
any kind of performance trouble, I just sometimes (once a *month*)
have to re-issue some db commands because of these
"deadlocks", but 99.9% of the time I have free cpu, free memory and
free disk IO resources so, fortunately, performace is not
a problem, just some deadlocks, and I just want to be sure that
everything works as it should, even in that 0.1% of the time that
the database is heavily used.
Additionally, the database that causes me this kind of troubles
is a database dedicated to batch jobs, so in any case nobody
will be angry if the jobs finish couple of minutes later than usual ...:)
It's something like: 23.5 hours a day data is loaded, 0.5 hours a day
some clients run in parallel and call some stored procedures
that can run in a serial fashion without causing any kind of trouble.
Thank you anyway, any e-mail is really appreciated, even if
performance is not a problem for me... and I hope that this sentence
will not make this e-mail be considered as spam .... :D
Greetings, and thanks again, Jerry!
Thanks even to Paul for the "really-tiny-but-really-appreciated"
answers to my questions!
2009/3/10 Jerry Schwartz <jschwartz@stripped>:
> [JS] There is no free lunch, but sometimes you get a free appetizer. Within
> limits, you will get better throughput if you have multiple transactions
> running in parallel rather than running them serially. The problem is to
> determine those limits. If you have the luxury, you run stress tests and
> examine the queue lengths for the various bits: disk, memory, cpu, network.
> That will give you some idea of what your system can tolerate, as well as
> telling you where to put your money. In reality, most of us run stress tests
> during production. :<(
> Of the various resources, memory is the one with the sharpest "knee in the
> curve" because either you have enough or you don't. If you have enough
> memory, then more will not help.
> Remember, there is always exactly one bottleneck in a system at any given
> By the way, if transactions are constantly presented to a resource faster
> than the resource can service, the queue length will grow to infinity. That
> will cause performance problems. ;<)