-mmax & -L parameters
- Thread starter SSuhaib
- Start date
TomBascom
Curmudgeon
-mmax is a client parameter. For character clients I usually start it at 4096, for GUI clients 8192.
-L is a server parameter. There is no simple rule of thumb for setting it as it depends entirely on the application. It is the total number of locks that might be concurrently held by all users at peak activity. If it is a well-written application this can be a fairly small multiple of the number of users. If your db has been successfully in use for a while and you don't get errors about -L needing to be increased then just monitor the high water mark and do nothing unless you're getting close. More often there is some (hopefully rare) misbehaving process that needs lots and lots of locks where the number of locks needed is related to the amount of data being processed. If that is the case then you get to set -L by trial and error.
-L is a server parameter. There is no simple rule of thumb for setting it as it depends entirely on the application. It is the total number of locks that might be concurrently held by all users at peak activity. If it is a well-written application this can be a fairly small multiple of the number of users. If your db has been successfully in use for a while and you don't get errors about -L needing to be increased then just monitor the high water mark and do nothing unless you're getting close. More often there is some (hopefully rare) misbehaving process that needs lots and lots of locks where the number of locks needed is related to the amount of data being processed. If that is the case then you get to set -L by trial and error.
tamhas
ProgressTalk.com Sponsor
If that is the case then you get to set -L by trial and error.
Sometimes, one can be more proactive than that. E.g., I had a case where the application as a whole was well behaved and -L could normally be quite low, but then there was one site that had a customer who regularly paid 7-8,000 invoices with a single check (publisher selling to Barnes and Noble with a separate invoice for every shipment to every store). The design of the application was such that there were three locks for every invoice and it was reasonable design, at least at the time, for making applying to all invoices a single transaction. So, we set -L to be large enough to handle that set of locks plus a bit for everyone else and all went smoothly.
In a more modern architecture one might design the application differently to avoid making it all one transaction, but this is an example where one can understand the business rule and accommodate it in a controlled fashion rather than just making it arbitrarily large to cover over bad code.
Sometimes, one can be more proactive than that. E.g., I had a case where the application as a whole was well behaved and -L could normally be quite low, but then there was one site that had a customer who regularly paid 7-8,000 invoices with a single check (publisher selling to Barnes and Noble with a separate invoice for every shipment to every store). The design of the application was such that there were three locks for every invoice and it was reasonable design, at least at the time, for making applying to all invoices a single transaction. So, we set -L to be large enough to handle that set of locks plus a bit for everyone else and all went smoothly.
In a more modern architecture one might design the application differently to avoid making it all one transaction, but this is an example where one can understand the business rule and accommodate it in a controlled fashion rather than just making it arbitrarily large to cover over bad code.
Similar threads
- Locked
- Anita Kyurova
- Progress Blog
- Locked
- Jessica Malakian
- Progress Blog