Parameter WRITE_LIMIT

system · August 23, 2011, 8:31pm

Sorry, I wanted to say, if you don’t use the default or ALL, try the default. If you use the default, specify ALL.

Matthias1 · August 24, 2011, 2:59pm

Thanks for the hint. It seems like we’re using default at the moment.

$ adaopr db=11 di=stat
%ADAOPR-I-STARTED,      24-AUG-2011 11:28:55, Version 6.1.10.10 (Solaris 64Bit)

Database 11, startup at 24-AUG-2011 07:03:28
ADANUC Version 6.1.10.10, PID 10458

                       ADANUC Version 6.1.10.10
        Database 11      Static Parameters      on 24-AUG-2011 11:28:55


Resources:         LAB       :    33,554,432    NT        :            30
                   LBP       :   536,870,912    NU        :         1,500
                   LWP       :    67,108,864    NCL       :         1,500

Logging:           PLOG, BI
Options:           TRUNCATION, OPEN_REQUIRED, AUTO_EXPAND

Userexits:         2

Cloglayout:        5

Adabas Access:     ALL

Unbuffered:        WORK, PLOG


%ADAOPR-I-TERMINATED,   24-AUG-2011 11:28:55, elapsed time: 00:00:00

Matthias1 · August 31, 2011, 1:35pm

We tried out UNBUFFERED=ALL for the past few days. There’s no positive or negative impact on Performance.

The buffer flush takes a little longer
~ 15 sec. with WRITE_LIMIT=5

30 sec. with WRITE_LIMIT=8

… but that’s no surprise.

Matthias1 · August 31, 2011, 8:40pm

Today I saw a phenomenon in connection with UNBUFFERED=ALL. The number of modified bytes can be greater than the write limit… Maybe this happens when there are more modifications than the storage can write for a longer time.

                       ADANUC Version 6.1.10.10
        Database 11    Buffer Pool Statistics   on 31-AUG-2011 10:23:59


Buffer Pool Size   :   536,870,912

Pool Allocation                        RABNs present
---------------                        -------------
Current     ( 99%) :   536,815,616     ASSO               :        44,813
Highwater   ( 99%) :   536,840,192     DATA               :        38,239
                                       WORK               :             0
                                       NUCTMP             :            14
                                       NUCSRT             :             0

I/O Statistics                         Buffer Flushes
--------------                         --------------
Logical Reads      : 1,982,497,623     Total              :           908
Physical Reads     :    18,208,505     To Free Space      :             0
Pool Hit Rate      :            99%
                                       Write Limit  (  5%):    26,843,500
Physical Writes    :     8,662,129     Modified     ( 16%):    87,568,384

Matthias1 · January 10, 2012, 6:06pm

Hello all!

There are some news about our problem.

We did an reorganization (i.e. reorder) of the database on Dec 30th.

The old duration of buffer flush:

Here are the new values:
WRITE_LIMIT=5 → <1 sec.
WRITE_LIMIT=8 → ~3 sec.
WRITE_LIMIT=27 → ~20 sec.

Seems like we should do a reorder more often…

Matthias

system · February 7, 2012, 6:33pm

Is there any problem with WRITE_LIMIT=1?

We have a BP with a modification rate of about 1.4%/hour. With WRITE_LIMIT=1 (minimun value) we would have a BF every (about) 43 minutes. We have checked and backup times do not get degraded. We do not have batch processing. Is there any other issue with WRITE_LIMIT=1? (for example, could we have BF overruns in a Windows environment?)
Thanks in advance

Matthias1 · February 8, 2012, 2:24pm

We tried it out and we got no (additional) problems with that value. But on the other hand, it didn’t solve our problems.
BTW: What’s the size of your buffer pool?

I think it would be less than 43 minutes - because pool size / flash rate is not linear.

With a WRITE_LIMIT of 5 we got ~ 5 Bufferflushes per hour during dialog time.

system · February 8, 2012, 4:04pm

The size of our Buffer Pool is 650.000.000.
With Write_Limit=0, the Adabas chosen value is 48%, which means no Buffer Flushes throughout the day (until backup), because “Modified” grows about 1.4% per online hour.

Matthias1 · February 16, 2012, 1:28pm

Finally we followed Wolfgang Obmann’s recommendation. We’ve increased our buffer pool to 1 GB last weekend. Our hit rate is now much better than 99%. Nethertheless it doesn’t solve our performance problems during buffer flush.

                       ADANUC Version 6.1.10.10
        Database 11    Buffer Pool Statistics   on 16-FEB-2012 13:26:56


Buffer Pool Size   : 1,073,741,824

Pool Allocation                        RABNs present
---------------                        -------------
Current     ( 99%) : 1,073,670,144     ASSO               :        55,222
Highwater   ( 99%) : 1,073,707,008     DATA               :        95,313
                                       WORK               :             0
                                       NUCTMP             :            52
                                       NUCSRT             :             0

I/O Statistics                         Buffer Flushes
--------------                         --------------
Logical Reads      : 4,126,167,769     Total              :           305
Physical Reads     :    24,269,102     To Free Space      :             0
Pool Hit Rate      :            99%
                                       Write Limit  (  3%):    32,212,230
Physical Writes    :     6,793,465     Modified     (  2%):    27,668,480


%ADAOPR-I-TERMINATED,   16-FEB-2012 13:27:00, elapsed time: 00:00:00

Matthias1 · August 3, 2012, 10:51am

Hello all!

A brief feedback:

Some weeks ago we moved the ADABAS database files + plog directory to a new harddisk device. The new one is faster - especially during I/O-peaks (like buffer flushes) it is three times faster.

Interestingly we can still reproduce dialog hangs. But we have to set the WRITE_LIMIT to a value >= 25 then (i.e. >= 250MB).

regards

Matthias