Hi there, 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! Mattia Merzi. 2009/3/10 Jerry Schwartz <jschwa...@the-infoshop.com>: [...] > [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 > moment. > > 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. ;<) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
