IDS Forum

AW: AW: Analysis of activities during checkpoint.

Posted By: Andreas.KUTSCHE@spar.at
Date: Wednesday, 2 July 2008, at 8:28 a.m.

In Response To: Re: AW: Analysis of activities during checkpoint. (VARTIKA AGRAWAL)

Hello,

you should change
NUMAIOVPS 2 # Number of IO vps
to something like
NUMAIOVPS 100

That should give you a performance boost - not only at checkpoint times.
You can add AIO-VPs online with onmode -p +<number> aio

You can watch IO processes with
onstat -g iov
If io/wup is high (2 or higher) you should add even more AIO-VPs.

If that doesn't reduce checkpoint times dramatically, you could try to lower
LRU_MIN_DIRTY and LRU_MAX_DIRTY to smaller (fractional) values:
LRU_MAX_DIRTY 1 (or 0.5)
LRU_MIN_DIRTY 0.5 (or 0.3)

For the INSERT operations:
Monitor several checkpoints - do you see critical INSERTs on that table?
If the Indices are detached (dbschema -ss -d <database> -t <table>) - check
size of the index fragments with: oncheck -pt <database>:<table>
If one/many indexes are larger than the table an index recreation could be
worth the effort.

If you habe attached indexes: oncheck -pt gives the usage of table pages
(data, other) - if you don't have binary data in the table (text, raw fields), the other pages are index pages. If other is much higher than data,
an index recreation ....
Attention: The DROP of attached indexes can need a lot of time!

Index creation should be done with PDQ_PRIORITY and PSORT_NPROCS set (for a quick start 50 , 8 ) - I'm not sure if MAX_PDQPRIORITY must be set to 100 ,
could be done with an onmode option.

Regards,
Andreas

>
-------------------------------------------
SPAR Österreichische Warenhandels-AG
Hauptzentrale
A - 5015 Salzburg, Europastrasse 3
FN 34170 a

Tel: +43 662 4470 24223
Mobile: +43 664 6259575
E-Mail: Andreas.KUTSCHE@spar.at
Internet: http://www.spar.at

Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und rechtlich geschützte Informationen, insbesondere Betriebs- oder Geschäftsgeheimnisse, enthalten, zu deren Geheimhaltung der Empfänger verpflichtet ist. Die Informationen in dieser E-Mail sind ausschließlich für den Adressaten bestimmt. Sollten Sie die E-Mail irrtümlich erhalten haben so ersuchen wir Sie, die Nachricht von Ihrem System zu löschen und sich mit uns in Verbindung zu setzen.
Über das Internet versandte E-Mails können leicht manipuliert oder unter fremdem Namen erstellt werden. Daher schließen wir die rechtliche Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftlich bestätigt und gezeichnet wird.
Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch die Zusendung von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht für evtl. hieraus entstehende Schäden.
Wir danken für Ihr Verständnis.

Important notice: The contents of this e-mail may contain confidential and legally protected information that is in particular related to operational and trade secrets, which the recipient is obliged to treat as confidential. The information in this e-mail is made available exclusively for use by the addressee. In the event that the e-mail may have been sent to you in error, we would ask you to kindly delete this communication from your system and to contact us.
E-mails sent via the Internet can be easily manipulated or sent out under someone else's name. We therefore do not accept legal liability for the information contained in this communication. The contents of the e-mail are only legally binding if they have been confirmed and signed by us in writing.
If, in spite of our using Antivirus protection software, a virus may have penetrated your system through the sending of this e-mail, we do not accept liability for any damage that may possibly arise as a result of this.
We trust that you appreciate our position.

-------------------------------------------
-----Ursprüngliche Nachricht-----

> Von: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] Im Auftrag von
> VARTIKA AGRAWAL
> Gesendet: Mittwoch, 02. Juli 2008 13:23
> An: ids@iiug.org
> Betreff: Re: AW: Analysis of activities during checkpoint. [12547]
>
> Thank you andreas,
>
> Please have a look at the onconfig entries -
> ROOTNAME rootdbs # Root dbspace name
> ROOTPATH /informix/P10/sapdata/physdev1/data01
> ROOTOFFSET 16 # Offset of root dbspace into device (Kbytes)
> ROOTSIZE 200000 # Size of root dbspace (Kbytes)
> MIRROR 1 # Mirroring flag (Yes = 1, No = 0)
> MIRRORPATH # Path for device containing mirrored root
> MIRROROFFSET 0 # Offset into mirrored device (Kbytes)
> PHYSDBS physdbs # Location (dbspace) of physical log
> PHYSFILE 800000 # Physical log file size (Kbytes)
> LOGFILES 600 # Number of logical log files 20/09/99
> LOGSIZE 500 # initial (!) Logical log size (Kbytes)
> MSGPATH /informix/P10/online.db10.p10.log # System message log file path
> CONSOLE /informix/P10/console.db10.p10.log # System console message path
> ALARMPROGRAM /informix/P10/etc/infodb_check.sh # Alarm program path
> TAPEDEV /dev/rmt/dbbkp # Tape device path
> TAPEBLK 1024 # Tape block size (Kbytes)
> TAPESIZE 208666624 # Maximum amount of data to put on tape (Kbytes)
> LTAPEDEV /dev/rmt/logbkp # Log tape device path
> LTAPEBLK 256 # Log tape block size (Kbytes)
> LTAPESIZE 30000000 # Max amount of data to put on log tape (Kbytes)
> STAGEBLOB # INFORMIX-OnLine/Optical staging area
> SERVERNUM 0 # Unique id corresponding to a OnLine instance
> DBSERVERNAME db10p10tcp # Name of default database server
> DBSERVERALIASES db10p10shm # List of alternate dbservernames
> NETTYPE ipcshm,,, # Override sqlhosts nettype parameters
> NETTYPE tlitcp,2,190,CPU # Override sqlhosts nettype parameters
> DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed env.
> RESIDENT 0 # Forced residency flag (Yes = 1, No = 0)
> MULTIPROCESSOR 1 # 0 for single-processor, 1 for multi-processor
> NUMCPUVPS 39 # Number of User (cpu) vps
> SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps to one
> MUTEX_WAIT_LISTS 0 # If non-zero, force use of mutex wait lists
> NOAGE 0 # Process aging
> AFF_SPROC 0 # Affinity start processor
> AFF_NPROCS 0 # Affinity number of processors
> LOCKS 8000000 # Maximum number of locks
> BUFFERS 1900000 # Maximum number of shared buffers
> NUMAIOVPS 2 # Number of IO vps
> PHYSBUFF 1024 # Physical log buffer size (Kbytes)
> LOGBUFF 32 # Logical log buffer size (Kbytes)
> LOGSMAX 625 # Maximum number of logical log files
> CLEANERS 125 # Number of buffer cleaner processes
> SHMBASE 0x10a000000 # Shared memory base address
> SHMVIRTSIZE 16777216 # initial virtual shared memory segment size
> SHMADD 500000 # Size of new shared memory segments (Kbytes)
> SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited
> CKPTINTVL 900 # Check point interval (in sec)[changed on 13-10-2002]
> LRUS 110 # Numbe2 of LRU queues
> LRU_MAX_DIRTY 2 # LRU percent dirty begin cleaning limit
> LRU_MIN_DIRTY 1 # LRU percent dirty end cleaning limit
> LTXHWM 45 # Long transaction high water mark percentage
> LTXEHWM 70 # Long transaction high water mark (exclusive)
> TXTIMEOUT 0x12c # Transaction timeout (in sec)
> STACKSIZE 256 # Stack size (Kbytes)
> OFF_RECVRY_THREADS 10 # Default number of offline worker threads
> ON_RECVRY_THREADS 10 # Default number of online worker threads
> BAR_BSALIB_PATH /usr/lib/sparcv9/ibsad001.so
> BAR_ACT_LOG /tmp/bar_act.log
> BAR_MAX_BACKUP 0
> BAR_RETRY 3
> BAR_NB_XPORT_COUNT 50
> BAR_XFER_BUF_SIZE 31
> RA_PAGES 32 # Number of pages to attempt to read ahead
> RA_THRESHOLD 30 # Number of pages left before next group
> DBSPACETEMP tmpdbs1,tmpdbs2,tmpdbs3 # Default temp dbspaces
> DUMPDIR /tmp # Preserve diagnostics in this directory
> DUMPSHMEM 0 # Dump a copy of shared memory
> DUMPGCORE 0 # Dump a core image using 'gcore'
> DUMPCORE 0 # Dump a core image (Warning:this aborts OnLine)
> DUMPCNT 1 # Number of shared memory or gcore dumps for
> FILLFACTOR 90 # Fill factor for building indexes
> USEOSTIME 0 # 0: use internal time(fast), 1: get time from OS(slow)
> MAX_PDQPRIORITY 0 # Maximum allowed pdqpriority
> DS_MAX_QUERIES # Maximum number of decision support queries
> DS_TOTAL_MEMORY # Decision support memory (Kbytes)
> DS_MAX_SCANS 1048576 # Maximum number of decision support scans
> DATASKIP off
> OPTCOMPIND 2 # To hint the optimizer
> ONDBSPACEDOWN 1 # Dbspace down option: 0 = CONTINUE, 1 = ABORT, 2 = WAIT
> LBU_PRESERVE 1 # Preserve last log for log backup
> OPCACHEMAX 128 # Maximum optical cache size (Kbytes)
> HETERO_COMMIT 0
> DD_HASHSIZE 613 # Length of DD Hash; 03-Nov-94
> DD_HASHMAX 30 # Width of DD Hash; 03-Nov-94
> CDR_LOGBUFFERS 2048 # size of log reading buffer pool (Kbytes)
> CDR_EVALTHREADS 1,1 # evaluator threads (per-cpu-vp,additional)
> CDR_DSLOCKWAIT 5 # DS lockwait timeout (seconds)
> CDR_QUEUEMEM 4096 # Maximum amount of memory for any CDR queue
> SYSALARMPROGRAM
> /informix/P10/etc/evidence.sh # System Alarm program path
> TBLSPACE_STATS 1
> CDR_LOGDELTA 30 # % of log space allowed in queue memory
> CDR_NUMCONNECT 16 # Expected connections per server
> CDR_NIFRETRY 300 # Connection retry (seconds)
> CDR_NIFCOMPRESS 0 # Link level compression (-1 never, 0 none, 9 max)
> ISM_DATA_POOL ISMData # If the data pool name is changed, be sure to
> ISM_LOG_POOL ISMLogs
> OPT_GOAL -1
> DIRECTIVES 1
> RESTARTABLE_RESTORE off
> BTSCANNER num=6,priority=high,threshold=600000,rangesize=500
> DYNAMIC_LOGS 2
> CDR_SERIAL 0,0 # Serial Column Sequence
> CDR_DBSPACE # dbspace for syscdr database
> CDR_QHDR_DBSPACE # CDR queue dbspace (default same as catalog)
> CDR_QDATA_SBSPACE # List of CDR queue smart blob spaces
> CDR_MAX_DYNAMIC_LOGS 0 # Dynamic log addition disabled by default
> BAR_DEBUG_LOG /tmp/bar_dbug.log # ON-Bar Debug Log - not in /tmp please
> BAR_PROGRESS_FREQ 0
> SBSPACENAME # Default smartblob space name - this is where blobs
> SYSSBSPACENAME # Default smartblob space for use by the Informix
> BLOCKTIMEOUT 3600 # Default timeout for system block
> ALLOW_NEWLINE 0 # embedded newlines(Yes = 1, No = 0 or anything but 1)
>
> The no of dirty buffers in onstat -R keeps on changing ( going up and down
> without any specific pattern).We do not use KAIO. we do use raw devices
> for
> chunks.
>
> This time onstat -u | grep X gave one entry which was an INSERT operation.
> This query was inserting data into a table thru a view. The underlying
> table
> has got 8 index but the same job runs fine for most of the time.
> how can i find the state of an index ie degenerated or healthy. ??
>
> pl. explain.
>
> regards,
> vartika.
>
>
> **************************************************************************
> *****
> Forum Note: Use "Reply" to post a response in the discussion forum.

Messages In This Thread

• Analysis of activities during checkpoint.
  VARTIKA AGRAWAL -- Wednesday, 2 July 2008, at 4:01 a.m.
  • Re: Analysis of activities during checkpoint.
    Martin Fuerderer -- Wednesday, 2 July 2008, at 4:21 a.m.
  • AW: Analysis of activities during checkpoint.
    Andreas.KUTSCHE@spar.at -- Wednesday, 2 July 2008, at 6:07 a.m.
    • Re: AW: Analysis of activities during checkpoint.
      VARTIKA AGRAWAL -- Wednesday, 2 July 2008, at 7:22 a.m.
      • AW: AW: Analysis of activities during checkpoint.
        Andreas.KUTSCHE@spar.at -- Wednesday, 2 July 2008, at 8:28 a.m.
        • Re: AW: AW: Analysis of activities during checkpoi
          VARTIKA AGRAWAL -- Friday, 4 July 2008, at 2:36 a.m.
          • AW: AW: AW: Analysis of activities during chec....
            Andreas.KUTSCHE@spar.at -- Friday, 4 July 2008, at 3:54 a.m.
            • Re: AW: AW: AW: Analysis of activities during chec
              VARTIKA AGRAWAL -- Friday, 4 July 2008, at 5:56 a.m.
              • AW: AW: AW: AW: Analysis of activities during ....
                Andreas.KUTSCHE@spar.at -- Friday, 4 July 2008, at 6:31 a.m.
                • Re: AW: AW: AW: AW: Analysis of activities during
                  VARTIKA AGRAWAL -- Thursday, 10 July 2008, at 7:44 a.m.
                  • AW: AW: AW: AW: AW: Analysis of activities dur....
                    Andreas.KUTSCHE@spar.at -- Thursday, 10 July 2008, at 8:33 a.m.
                    • Re: AW: AW: AW: AW: Analysis of activities dur....
                      Keith Simmons -- Thursday, 10 July 2008, at 9:19 a.m.
                  • Re: AW: AW: AW: AW: Analysis of activities dur....
                    Art Kagel -- Thursday, 10 July 2008, at 11:49 a.m.
                    • Re: AW: AW: AW: AW: Analysis of activities dur....
                      VARTIKA AGRAWAL -- Friday, 11 July 2008, at 3:46 a.m.
                      • Re: AW: AW: AW: AW: Analysis of activities dur....
                        Amitava Chakraborty -- Friday, 11 July 2008, at 4:29 a.m.
                        • Re: AW: AW: AW: AW: Analysis of activities dur....
                          VARTIKA AGRAWAL -- Friday, 11 July 2008, at 5:19 a.m.
                          • AW: AW: AW: AW: AW: Analysis of activities dur....
                            Andreas.KUTSCHE@spar.at -- Friday, 11 July 2008, at 6:04 a.m.
                          • Re: AW: AW: AW: AW: Analysis of activities dur....
                            Art Kagel -- Friday, 11 July 2008, at 10:57 a.m.
                      • RE: AW: AW: AW: AW: Analysis of activities dur....
                        Flores, J. Gerardo -- Friday, 11 July 2008, at 11:05 a.m.
  • Re: Analysis of activities during checkpoint.
    Art Kagel -- Wednesday, 2 July 2008, at 8:52 a.m.
    • Re: Analysis of activities during checkpoint.
      coral80@gmx.de -- Wednesday, 2 July 2008, at 9:52 a.m.
      • Re: Analysis of activities during checkpoint.
        JAN VIRT -- Wednesday, 2 July 2008, at 10:31 a.m.
        • Re: Analysis of activities during checkpoint.
          VARTIKA AGRAWAL -- Thursday, 3 July 2008, at 2:42 a.m.
          • Re: Analysis of activities during checkpoint.
            JAN VIRT -- Thursday, 3 July 2008, at 6:04 a.m.
            • Re: Analysis of activities during checkpoint.
              H.G -- Thursday, 3 July 2008, at 3:54 p.m.
    • Re: Analysis of activities during checkpoint.
      CURTIS CROWSON -- Tuesday, 8 July 2008, at 11:29 a.m.
      • Re: Analysis of activities during checkpoint.
        Art Kagel -- Tuesday, 8 July 2008, at 3:08 p.m.
        • RE: Analysis of activities during checkpoint.
          Larry Sorensen -- Tuesday, 8 July 2008, at 5:52 p.m.
          • RE: Analysis of activities during checkpoint.
            John Miller iii -- Tuesday, 8 July 2008, at 6:17 p.m.
            • RE: Analysis of activities during checkpoint.
              Tim Ertl -- Wednesday, 9 July 2008, at 8:39 p.m.
          • Re: Analysis of activities during checkpoint.
            Fernando Nunes -- Tuesday, 8 July 2008, at 6:19 p.m.
          • Re: Analysis of activities during checkpoint.
            Art Kagel -- Tuesday, 8 July 2008, at 8:44 p.m.
            • Re: Analysis of activities during checkpoint.
              CURTIS CROWSON -- Wednesday, 9 July 2008, at 8:22 a.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.