Performance issue
Challenger212 Abderrafi reported that a batch updating a huge table slowed dramatically when another batch deleted rows from a partitioned table; parallel loads via external tables were also slow. Sergio Peres asked about statistics, which were current. Eric Vercelletto listed possible causes: inefficient application code, constraint locks, heavy indexing on deletes, poor IO or small buffer cache. Unresolved.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Hi, I have a performance problem, when I Launch a workload batch which do many updates on a huge table, it work well but when I launch in parrallel an other batch wich delete many rows from an other partionned table, the perfomance for the first batch slow down dramaticaly, so why that is happening, should I launch no more than one batch ?
Hi, Do you have statistics updated?
yes, all updated, When I launch two for ewxmaple loading on two big partionned tables its gone inserting too slow, what'is the matter, I work with external tables in inserting, is the problem is partition, plz help, me to understand whats the matter. thanks
Informix 11.50.FC8. Solaris 10 sparc
What are some good monitoring statistics that can be gathered throughout the
day with onstat or scripts and that are non evasive? We would like to monitor
the database for a week or two, make some changes, and then see if the
statistics change for the better.
Larry
> To: ids@iiug.org
> From: sergio.peres@airc.pt
> Subject: Re: Performance issue [36257]
> Date: Tue, 15 Dec 2015 15:23:35 -0500
>
> Hi,
>
> Do you have statistics updated?
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
hi, the reasons can be multiple: - the way the application works: it can simply be coded in an very inefficient way, causing conflicts and unuseful repetitions that can be very costly - locks: check if you have relational constraints that will put locks on related tables, also causing conflicts - if the table that you delete rows has complex/numerous indexes, deleting rows massively can take huge times - bad IO thruput / poor write cache pointing to too small BUFFER cache