IDS Forum

RE: Poor performance on replacement server

Posted By: Phil Torkington
Date: Wednesday, 14 December 2005, at 7:43 a.m.

In Response To: Re: Poor performance on replacement server (John Bejarano )

You can also check the number of sql statements which are performing
sequential scans or just have a high cost associated with them.

Onstat -p will give you the number of seq scans performed on the system
since the system was started (or you zero'd the stats) then you could
profile the sql running through your system by collecting a snapshot of
current sql every 5 minutes (this period seems to work for us and is a
good place to start) using the sysmaster tables (there's a flag in there
which tells you if the query is perfoming a seq scan and also gives you
the estimated cost of the query). This will enable you to identify any
poor performing sql during the peak load time.

If you want to pursue this let me know if you need the sysmaster sql.

-----Original Message-----
From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org] On
Behalf Of John Bejarano
Sent: 13 December 2005 17:04
To: ids@iiug.org
Subject: Re: Poor performance on replacement server [6089]

Could this be users waiting on locks? Occasionally, after a certain
threshold, lock waiting can begin to cascade and get worse in an
apparently step-wise fashion. Try placing a monitor on the number of
locks to see if that all of a sudden jumps. If it does, it may indicate
that a transaction in the application may need to be made more
efficient.

--John Bejarano.


--- Simon Coyne <simon.coyne@dla.com> wrote:

> Dear Informix users
>
> The firm I work for have recently purchased a 4 processor ES45 Alpha
> server to run our practice management (sales ledger) system. This is
> replacing a 2 processor DS25 Alpha server (which struggles at period
> end). Outline specification is
>
> 4x1.2Ghz Alpha processors
> 8Gb RAM
> 5304 4 Channel Ultra SCSI controller
> 2xMA300(I think) disk cages populated with 36Gb disks and configured
> as RAID 1+0 for both OS and Informix raw chunks.
> Tru 64 5.1B
> Informix 9.3.FC3
>
> The instance is about 80Gb total.
>
> Unfortunately, we are experiencing crippling performance problems.
> When we get to about 55 green screen users on the system, performance
> within Informix becomes terrible. The 3 CPU VPs go to 100% and disk
> I/O drops to almost 0 across every one of the Informix disks. On
> occassion, when CPU utilisation dips below ~85%, disk I/O goes back to

> normal levels and performance is great. At all times, the disk
> performance for O/S based operations is more than acceptable. Informix

> performance is almost binary; it's either working or stopped. There
> doesn't seem to be an inbetween position where performance starts
> degrading.
>
> Has anyone seen anything like this at all or have any helpful
> suggestions? (Update statistics runs
> daily.)
>
> Thanks in advance
>
>
> Simon Coyne
> Infrastructure Specialist
> DLA Piper Rudnick Gray Cary LLP
>
> ONconfig follows
>
>
#***********************************************************************
***
> #
> # INFORMIX SOFTWARE, INC.
> #
> # Title: onconfig.std
> # Description: Informix Dynamic Server 2000 Configuration Parameters
> #
>
#***********************************************************************
***
>
> # Root Dbspace Configuration
>
> ROOTNAME rootdbs # Root dbspace name
> ROOTPATH /dev/rootdbs # Path for device
> containing root dbspace
> ROOTOFFSET 500 # Offset of root
> dbspace into device (Kbytes)
> ROOTSIZE 2000000 # Size of root
> dbspace (Kbytes)
>
> # Disk Mirroring Configuration Parameters
>
> MIRROR 0 # Mirroring flag
> (Yes = 1, No = 0)
> MIRRORPATH # Path for device
> containing mirrored root
> MIRROROFFSET 0 # Offset into
> mirrored device (Kbytes)
>
> # Physical Log Configuration
>
> PHYSDBS physdbs # Location (dbspace)
> of physical log
> PHYSFILE 1000000 # Physical log file
> size (Kbytes)
>
> # Logical Log Configuration
>
> LOGFILES 1034 # Number of logical
> log files
> LOGSIZE 1500 # Logical log size
> (Kbytes)
>
> # Diagnostics
>
> MSGPATH /usr/informix/online.log # System
> message log file path
> CONSOLE /usr/informix/console.log # System
> console message path
> ALARMPROGRAM /usr/informix/etc/log_full.sh #
> Alarm program path
> TBLSPACE_STATS 1 # Maintain tblspace
> statistics
>
> # System Archive Tape Device
>
> TAPEDEV /devices/tape/tape17c # Tape device
> path
> #TAPEDEV /devices/tape/tape16c # FS Backup
> device
> #TAPEDEV /dev/null # Black Hole
> #TAPEDEV /nfsdump/aristadbbackup.img
> TAPEBLK 1024 # Tape block size
> (Kbytes)
> TAPESIZE 85000000 # Maximum amount of
> data to put on tape (Kbytes)
>
> # Log Archive Tape Device
>
> LTAPEDEV /devices/tape/tape16
> LTAPEBLK 1024 # Log tape block
> size (Kbytes)
> LTAPESIZE 35000000 # Max amount of data
> to put on log tape (Kbytes)
>
> # Optical
>
> STAGEBLOB # Informix Dynamic
> Server 2000 staging area
>
> # System Configuration
>
> SERVERNUM 0 # Unique id
> corresponding to a OnLine instance
> DBSERVERNAME arista # Name of default
> database server
> DBSERVERALIASES arista_tcp # List of alternate
> dbservernames
> DEADLOCK_TIMEOUT 60 # Max time to wait
> of lock in distributed env.
> RESIDENT 0 # Forced residency
> flag (Yes = 1, No = 0)
>
> MULTIPROCESSOR 0 # 0 for
> single-processor, 1 for multi-processor
> NUMCPUVPS 2 # Number of user
> (cpu) vps
> SINGLE_CPU_VP 0 # If non-zero, limit
> number of cpu vps to one
>
> NOAGE 0 # Process aging
> # NRW changed proc affinity to second cpu to help system performance
> AFF_SPROC 0 # Affinity start
> processor
> AFF_NPROCS 0 # Affinity number of
> processors
>
> # Shared Memory Parameters
>
> LOCKS 1000000 # Maximum number of
> locks
> #[was] BUFFERS 300000 # Maximum
> number of shared buffers
> #[was] BUFFERS 400000 # Maximum
> number of shared buffers
> BUFFERS 500000 # Maximum number of
> shared buffers
> NUMAIOVPS 16 # Number of IO vps
> #[was] PHYSBUFF 655 # Physical
> log buffer size (Kbytes)
> PHYSBUFF 864 # Physical log
> buffer size (Kbytes)
> #[was] LOGBUFF 32 # Logical log
> buffer size (Kbytes)
> LOGBUFF 38 # Logical log buffer
> size (Kbytes)
> LOGSMAX 2048 # Maximum number of
> logical log files
> CLEANERS 16 # Number of buffer
> cleaner processes
> SHMBASE 0x200000000 # Shared memory
> base address
> #[was] SHMVIRTSIZE 155648 # initial
> virtual shared memory segment size
> #[was] SHMVIRTSIZE 188416 # initial
> virtual shared memory segment size
> SHMVIRTSIZE 753644 # initial virtual
> shared memory segment size
> #[was] SHMADD 16000 # Size of new
> shared memory segments (Kbytes)
> #[was] SHMADD 18841 # Size of new
> shared memory segments (Kbytes)
> SHMADD 75366 # Size of new shared
> memory segments (Kbytes)
> SHMTOTAL 0 # Total shared
> memory (Kbytes). 0=>unlimited
> CKPTINTVL 300 # Check point
> interval (in sec)
> LRUS 128 # Number of LRU
> queues
> LRU_MAX_DIRTY 3 # LRU percent dirty
> begin cleaning limit
> # [was] LRU_MAX_DIRTY 10 # LRU
> percent dirty begin cleaning limit
>
=== message truncated ===



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Messages In This Thread

• Poor performance on replacement server
  Simon Coyne -- Tuesday, 13 December 2005, at 11:03 a.m.
  • Re: Poor performance on replacement server
    John Bejarano -- Tuesday, 13 December 2005, at 12:03 p.m.
    • RE: Poor performance on replacement server
      Phil Torkington -- Wednesday, 14 December 2005, at 7:43 a.m.
  • Re: Poor performance on replacement server
    Ravi T -- Tuesday, 13 December 2005, at 1:30 p.m.
  • RE: Poor performance on replacement server
    Rafael Padilla V -- Tuesday, 13 December 2005, at 2:01 p.m.
  • RE: Poor performance on replacement server
    Art S. Kagel -- Tuesday, 13 December 2005, at 2:56 p.m.
  • RE: Poor performance on replacement server
    simon@coynes.eclipse.co.uk -- Wednesday, 14 December 2005, at 4:59 a.m.
    • RE: Poor performance on replacement server
      ART KAGEL, BLOOMBERG/ 731 LEXIN -- Wednesday, 14 December 2005, at 12:39 p.m.
    • RE: Poor performance on replacement server
      Ravi T -- Wednesday, 14 December 2005, at 12:50 p.m.
    • Re: RE: Poor performance on replacement server
      DARKO KRSTIC -- Wednesday, 14 December 2005, at 1:59 p.m.
    • RE: Poor performance on replacement server
      Simon -- Wednesday, 14 December 2005, at 7:00 p.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.