Tamaño del log físico

IDS 12.10.FC9W1 AIX 7 Estoy intentando calcular si el tamaño de nuestro Log Físico (Physical Log) es lo suficientemente grande. Mi motivo: Checkpoint Completed: duration was 171 seconds. A veces nos afectan checkpoints muy grandes. Del manual: ---------------- Para asegurarse de disponer de espacio de sobra, establezca el tamaño del log físico en al menos el 110 por ciento del tamaño de todos los buffer pools. Desde mi servidor: --------------- BUFFERPOOL size=4K,buffers=21750000,lrus=256,lru_min_dirty=0.00,lru_max_dirty=0.50 BUFFERPOOL size=8K,buffers=2625000,lrus=128,lru_min_dirty=0.00,lru_max_dirty=0.50 BUFFERPOOL default,buffers=1000,lrus=22,lru_min_dirty=50.00,lru_max_dirty=60.00 Aquí es donde me atasco. ¿Debo fijarme en el total del Bufferpool (4k + 8k)? ¿O debo profundizar más y, en ese caso, cómo?

Otra pregunta, sobre esto: PHYSDBS physdbs # Ubicación (dbspace) del log físico PHYSFILE 54000000 # Tamaño del archivo de log físico (Kbytes) PHYSBUFF 4096 # Tamaño del búfer del log físico (Kbytes) Si aumento este valor, ¿puedo volver a disminuirlo?

Hola Dirk: No conozco tu sistema, pero a menos que tengas una razón concreta para sospechar del tamaño del log físico, no creo que sea una causa probable, sobre todo teniendo en cuenta que ya es bastante grande. Yo empezaría por examinar qué está ocurriendo durante los checkpoints lentos. ¿Tienes salida de 'onstat -g ckp' o de sysadmin:mon_checkpoint, suponiendo que tengas en ejecución el trabajo del planificador mon_checkpoint? Sería interesante ver el checkpoint lento junto a uno o dos checkpoints "buenos". Durante un checkpoint largo, ¿aproximadamente cuánto tiempo pasa el servidor en los estados 'CKPT REQ' y 'CKPT INP' (compruébalo con 'onstat -')? Cuando está en 'CKPT INP', ¿has capturado datos de 'onstat -F' que muestren qué flushers están activos y sobre qué chunks están trabajando? Ben.

Gracias por su respuesta. Tendré que RTFM respecto a esto. Por ahora me supera un poco. Mientras tanto, comparto el onstat -g ckp: (al final indica que el log físico podría ser demasiado pequeño) onstat -g ckp IBM Informix Dynamic Server Version 12.10.FC9W1 -- On-Line -- Up 13 days 08:48:59 -- 227111520 Kbytes AUTO_CKPTS=On RTO_SERVER_RESTART=Off Critical Sections Physical Log Logical Log Clock Total Flush Block # Ckpt Wait Long # Dirty Dskflu Total Avg Total Avg Interval Time Trigger LSN Time Time Time Waits Time Time Time Buffers /Sec Pages /Sec Pages /Sec 790824 11:29:09 CKPTINTVL 13144:0xb237f8c 4.5 4.1 0.0 50 0.0 0.2 0.3 55070 13344 367615 1127 91 0 790825 11:34:19 CKPTINTVL 13144:0xb25273c 5.2 4.8 0.0 48 0.0 0.3 0.3 45834 9606 231831 750 27 0 790826 11:39:27 CKPTINTVL 13144:0xb264424 2.8 2.5 0.0 37 0.0 0.1 0.2 80756 31708 142367 457 18 0 790827 11:44:41 CKPTINTVL 13144:0xb2ba4bc 7.6 7.2 0.0 43 0.0 0.2 0.2 84469 11689 127533 412 86 0 790828 11:49:44 CKPTINTVL 13144:0xb2cc2ac 2.3 2.0 0.0 43 0.0 0.2 0.2 75226 37138 157719 512 18 0 790829 11:54:50 CKPTINTVL 13144:0xb2f13b4 4.3 4.0 0.0 49 0.0 0.2 0.2 74725 18888 349106 1148 37 0 790830 11:59:56 CKPTINTVL 13144:0xb30f13c 3.4 3.1 0.0 48 0.0 0.2 0.2 37980 12436 534563 1741 30 0 790831 12:05:11 CKPTINTVL 13144:0xb323c58 6.2 4.8 0.0 92 0.0 0.9 1.1 53189 11091 818213 2614 20 0 790832 12:10:22 CKPTINTVL 13144:0xb3348b0 5.7 5.1 0.0 60 0.0 0.2 0.3 44907 8763 498561 1603 17 0 790833 12:15:29 CKPTINTVL 13144:0xb371084 4.6 4.2 0.0 44 0.0 0.2 0.3 70508 16985 564826 1833 61 0 790834 12:20:37 CKPTINTVL 13144:0xb392e74 4.9 4.6 0.0 40 0.0 0.2 0.2 42949 9320 595028 1931 33 0 790835 12:25:51 CKPTINTVL 13144:0xb3f0b0c 8.6 8.2 0.0 31 0.0 0.2 0.3 50988 6205 493491 1591 95 0 790836 12:31:05 CKPTINTVL 13144:0xb406230 4.3 4.0 0.0 25 0.0 0.1 0.2 55619 13844 365788 1150 22 0 790837 12:36:10 CKPTINTVL 13144:0xb41beb4 3.4 3.1 0.0 21 0.0 0.2 0.3 44075 14363 216661 708 21 0 790838 12:41:17 CKPTINTVL 13144:0xb483018 6.4 6.0 0.0 24 0.0 0.1 0.2 61208 10166 105972 348 104 0 790839 12:46:29 CKPTINTVL 13144:0xb49b0e8 8.3 8.0 0.0 22 0.0 0.2 0.2 52890 6589 135857 438 24 0 790840 12:51:36 CKPTINTVL 13144:0xb86e2bc 6.9 6.6 0.0 18 0.0 0.1 0.2 58071 8861 101357 328 979 3 790841 12:56:45 CKPTINTVL 13144:0xb8828fc 5.9 5.5 0.0 24 0.0 0.1 0.2 54951 10042 180011 580 20 0 790842 13:02:10 CKPTINTVL 13144:0xb899710 24.2 23.8 0.0 39 0.0 0.2 0.3 62783 2638 294797 963 23 0 790843 13:06:50 CKPTINTVL 13144:0xb8b1e54 4.7 4.2 0.0 24 0.0 0.2 0.3 55090 13048 617363 2057 24 0 Max Plog Max Llog Max Dskflush Avg Dskflush Avg Dirty Blocked pages/sec pages/sec Time pages/sec pages/sec Time 29703 1534 1985 9331 33 0 Based on the current workload, the physical log might be too small to accommodate the time it takes to flush the buffer pool during procesamiento de puntos de comprobación del usuario. El servidor podría bloquear las transacciones durante los puntos de comprobación. Si el servidor bloquea las transacciones, aumente el tamaño del registro físico hasta al menos 240000240 KB.

Revisando la salida de 'onstat -g ckp', la mayor parte del tiempo se consume vaciando datos a disco, lo que significa que su servidor debería estar en el estado 'CKPT INP' durante la mayor parte del checkpoint. El siguiente paso es recopilar datos de 'onstat -F' durante un checkpoint largo, digamos que cada segundo. Habría que buscar chunks concretos que tarden mucho tiempo en vaciarse. El paso siguiente sería entender qué contienen esos chunks (oncheck -pe) y por qué hay tantos cambios que vaciar. Posiblemente podría reubicar objetos para equilibrar la carga entre más chunks, reduciendo así el tiempo de vaciado. Dependiendo del esfuerzo que esto suponga, quizá convenga plantearse si los checkpoints largos son realmente un problema o no, ya que deberían ser no bloqueantes. También vale la pena revisar las tasas de E/S de disco. El mensaje básicamente indica que, para que un checkpoint no bloqueante funcione, el log físico debe ser lo suficientemente grande como para albergar los cambios que se producen mientras se ejecuta el checkpoint. En teoría, el sistema podría necesitar vaciar todas las páginas del buffer pool. Si el log físico es demasiado pequeño, el sistema se bloqueará hasta que finalice el checkpoint. Con los datos proporcionados no veo que esto esté ocurriendo en su sistema, y la sugerencia de 1,1 veces el total de los buffer pools corresponde al peor de los casos. Ben.