![]() | |
#1
| |||
| |||
|
|
That's an awful lot of log buffers. I question whether that many buffers are doing you any good. (It's not impossible, if you have really large updating transactions, just unlikely.) Starting with 2.6 (I think), multiple rollbacks can proceed concurrently, and in any case I don't think that rollback would stall a commit. I suspect that you ran into either some sort of hardware hiccup, or a consistency-point wait (BCP wait) that took a really long time for some unknown reason. But I don't really know. Karl There are 10000(4k) buffers configured. I didn't found any performace gains in further increasing this amount. But it serves us much better than previously configured 4000. Those buffers are for: 4 primary dbms servers (16 log writers each), 2 secondary dbms servers (1 log writer each) Recovery server (16 log writers). Total: 80 log writers (125 buffers per thread). Mystery of long commit resolved: transaction log was under heavy load - see attachment for key values from logstat before, and after transaction. BTW unfortunately transaction log is sharing devices with other filesystems - configuring a server is always a compromise. Regards, Artur Fajok ------------------------------------------------------------------------ +---------------+---------------+-------------------------+-------------+-------------+-------------+-------------+-------------+--------------+-------------+--------------+--------------+-------------------+-------------------+ |machine_name |machine_ip |date log_read_ios |log_write_ios|log_writes |log_forces log_split_wai|log_free_waits|log_bcp_waits|kbytes_ written|write_complete|all_logwriters_busy|max_wri te_queue_cnt| +---------------+---------------+-------------------------+-------------+-------------+-------------+-------------+-------------+--------------+-------------+--------------+--------------+-------------------+-------------------+ |sun480 |10.66.134.69 |050303 21:16:20 | 752082| 747115| 9678627| 103909| 6742| |
|
|sun480 |10.66.134.69 |050303 21:32:29 | 818072| 822283| 10164158| 105886| 10742| |
| +---------------+---------------+-------------------------+-------------+-------------+-------------+-------------+-------------+--------------+-------------+--------------+--------------+-------------------+-------------------+ |
#2
| |||
| |||
|
|
I read a article which was attached below and wonder if I should configure number of log writers while I don't find the parameter in CBF. BTW, what's the recommended value for buffer_count ? Currently buffer_count was 1000 in my server while its default value is 20. |
#3
| |||
| |||
|
|
"Frank Fan" <jun_fan4 (AT) agilent (DOT) com> wrote in message news:1110261658.16141 (AT) cswreg (DOT) cos.agilent.com... I read a article which was attached below and wonder if I should configure number of log writers while I don't find the parameter in CBF. BTW, what's the recommended value for buffer_count ? Currently buffer_count was 1000 in my server while its default value is 20. In 2.6, log_writers is a derived DBMS Server Parameter in CBF. (So if you change it, remember to protect it too.) You'd need to run the system for a while and then look at the output from logstat -statistics to see what is going on, but 1,000 log buffers is cheap enough, and likely to be good enough for most systems. The same report will tell you how often all the log writers were in use, and how often sessions were stalled waiting for log buffers. Using that information you would decide whether or not to run more log writer threads. A couple or ten is usually good enough. Give or take. I am absolutely not going to discourage anyone from tuning the logging system, but it's not a real high priority if it is at least working. Unless it is catastrophically wrong, it is unlikely to be the cause of any noticeable performance problems. (As we discussed before, the risk of losing the log file is a much bigger worry; be sure to mirror it somehow.) Roy Hann (rhann at rationalcommerce dot com) Rational Commerce Ltd. www.rationalcommerce.com "Ingres development, tuning, and training experts" |
![]() |
| Thread Tools | |
| Display Modes | |
| |