RES: ER performance

The degradation is on the source server. I would say it appears that the source is having to work too hard to get stuff in. I'm saying that because the tables that are on the repl catalog corresponds to just 20% of the system throughtput. The weirdest thing is that even if I stop the replicates, the system keep slow. Only if a drop/delete the replicates the systems back to normal behavior. I'll try to increase the queue memory to see what happens. Thanks again, Julio -----Mensagem original----- De: Madison Pruet [mailto:mpruet@comcast.net] Enviada em: quinta-feira, 29 de janeiro de 2004 15:18 Para: Julio Cesar Assunto: Re: ER performance We would need to understand where the performance hit is occurring. That's going to take a bit of time and would probably be best done by using a bit of consulting. Is the degradation on the source or the target? If the apply is having problems, you might be able to split the replicates into multiple replicates by using the mod function to partition the table and turning on the parallelize option on the replicate definition. Does it appear that the source is having to work too hard to get stuff out? This could be happening because the queue memory size is a bit too small and causing flushing to/from disk. "Julio Cesar" <julio@prodesmaq.com.br> wrote in message news:bvao2e$sid$1@terabinaries.xmission.com... > > I'm considering it more than ever now. I was planning to do such thing to > avoid the limitation of use HDR + ER. > While I'm planning that, is there something I could do to at least improve > performance a little? > > Thanks, > Julio > > -----Mensagem original----- > De: Madison Pruet [mailto:mpruet@comcast.net] > Enviada em: quarta-feira, 28 de janeiro de 2004 20:02 > Para: Julio Cesar > Assunto: Re: ER performance > > There's been a huge amount of work done on ER since the 7.31 days. And a > huge amount of the work has been focused on performance. > > 7.31 does not have nearly the parallelism with ER as 9.3+ and the queue > spooling treatment has been significantly improved. Both of these changes > will impact performance as well as use current resources much more > efficiently. Have you considered migration to 9.4? > > M.P. > > > "Julio Cesar" <julio@prodesmaq.com.br> wrote in message > news:bv96qe$2q9$1@terabinaries.xmission.com... > > > > This is a multi-part message in MIME format. > > > > ------=_NextPart_000_0001_01C3E5CA.48A6EEC0 > > Content-Type: text/plain; > > charset="Windows-1252" > > Content-Transfer-Encoding: quoted-printable > > > > Informix 7.31UD1 > > Linux (Redhat 8.0) > > > > On two servers:=20 > > DELL Poweredge 2650 Intel Xeon 2,8 (w/ 2 CPUs each), 2GB RAM each. > > > > My onconfig is attached to this message. > > > > Thanks > > > > -----Mensagem original----- > > De: Madison Pruet [mailto:mpruet@comcast.net]=20 > > Enviada em: quarta-feira, 28 de janeiro de 2004 17:49 > > Para: Julio Cesar > > Assunto: Re: ER performance > > > > Version??? > > > > Configuration??? > > > > > > "Julio Cesar" <julio@prodesmaq.com.br> wrote in message > > news:bv939u$10l$1@terabinaries.xmission.com... > > > > > > Hi guys, > > > A few weeks ago I got ER working on two servers between my companies. > > Since > > > that, I'm experiencing a lot of performance issues that I'd never = > > passed > > > through before. > > > The replication is working pretty fine but the server is completely > > > overloaded. > > > > > > I think I've checked out everything, although I couldn't find out what > > might > > > be happening. I just notice that cpu vps are getting overloaded = > > according > > a > > > "onstat -g glo" output. Also, locks on tables are taking longer than = > > ever > > to > > > be released. > > > > > > What should I check to solve that? > > > > > > ---- > > > By the way, I have DELL Servers with 2 Intel XEON processors, with > > > Hyperthreading enabled. On Linux, the system recognize 4 processors > > ('cause > > > of hyperthreading). With that, should I use 2 or 4 CPU Vps? What's = > > better? > > > --- > > > > > > PS: I did a test, turning off all the 1500 replicates and the systems = > > got > > > faster as it they were before. > > > > > > Thanks in advance, > > > Julio > > > > > > --- > > > Outgoing mail is certified Virus Free. > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > Version: 6.0.568 / Virus Database: 359 - Release Date: 26/1/2004 > > > > > > > > > > > > sending to informix-list > > > > > > > > --- > > Incoming mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.568 / Virus Database: 359 - Release Date: 26/1/2004 > > =20 > > > > --- > > Outgoing mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.568 / Virus Database: 359 - Release Date: 26/1/2004 > > =20 > > =20 > > > > ------=_NextPart_000_0001_01C3E5CA.48A6EEC0 > > Content-Type: application/octet-stream; > > name="onconfig" > > Content-Transfer-Encoding: quoted-printable > > Content-Disposition: attachment; > > filename="onconfig" > > > > =0A= > > Informix Dynamic Server Version 7.31.UD1 -- On-Line -- Up 2 days = > > 05:26:50 -- 1019684 Kbytes=0A= > > =0A= > > Configuration File: /opt/informix/etc/onconfig_db_pri=0A= > > #************************************************************************= > > **=0A= > > #=0A= > > # INFORMIX SOFTWARE, INC.=0A= > > #=0A= > > # Title: onconfig.prodesmaq=0A= > > # Description: Informix Dynamic Server Configuration Parameters=0A= > > #=0A= > > #************************************************************************= > > **=0A= > > =0A= > > # Root Dbspace Configuration=0A= > > =0A= > > ROOTNAME rootdbs # Root dbspace name=0A= > > ROOTPATH /mnt/informix_raw/rootdbs_1 =0A=> > # Path for device containing root > dbspace=0A= > > ROOTOFFSET 0 # Offset of root dbspace into device = > > (Kbytes)=0A= > > ROOTSIZE 1024000 # Size of root dbspace (Kbytes)=0A= > > =0A=> > # Disk Mirroring Configuration Parameters=0A= > > =0A= > > MIRROR 0 # Mirroring flag (Yes =3D 1, No =3D 0)=0A= > > MIRRORPATH # Path for device containing mirrored = > > root=0A= > > MIRROROFFSET 0 # Offset into mirrored device (Kbytes)=0A= > > =0A=> > # Physical Log Configuration=0A= > > =0A= > > PHYSDBS rootdbs # Location (dbspace) of physical log=0A= > > PHYSFILE 65536 # Physical log file size (Kbytes)=0A= > > =0A=> > # Logical Log Configuration=0A= > > =0A= > > LOGFILES 15 # Number of logical log files=0A= > > LOGSIZE 65536 # Logical log size (Kbytes)=0A= > > =0A=> > # Diagnostics