MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Egor Egorov Date:October 16 2002 7:51am
Subject:re: re: High load with "cleaning up" status
View as plain text  
Hello Mike,

Monday, October 14, 2002, 6:48:36 PM, you wrote:

>>MZ> Recently our DB, which is running MySQL 3.23.52, started experiencing
>>MZ> intermittant load spikes, of the magnitude of 200+ load averages. 
>>Normally,
>>MZ> our high spike is about 0.90 load. When this starts happening, we 
>>notice a
>>MZ> lot of processes "cleaning up" within the database. Can someone clue 
>>me in
>>MZ> as to what cleaning up means, and what the possible cause of this is?
>>
>>Sure, we can.
>>
>>Please tell us:
>>
>>- what is the exact mysql version running (build)

MZ> Version string: mysqld  Ver 3.23.52 for pc-linux-gnu on i686
MZ> Straight off the RPMs from the MySQL download mirrors.

Is it a mysql official binary or just a recompiled src.rpm?
You should only use official binaries.

MZ> memlock

>>- how does the table looks like (structure/type/properties)

>>- what is the hardware

MZ> Dual AthlonMP 1600+, 1GB RAM, RAID-5 configuration on the DB filesystem.

>>- what are the OS details

MZ> The session table would be a HEAP, but for the text field. As a compromise,
MZ> the MYD and MYI files are in /dev/shm.

Ok. First, I would move the table to a disk. It's just my guess. I
believe, memlock and MyISAM-in-memory may be a cause of a conflict.
Another try is to remove memlock option but leave data in ram.

Second, let's go thru variables:

  key_buffer_size Index blocks are buffered and are shared by all
  threads. key_buffer_size is the size of the buffer used for index
  blocks. Increase this to get better index handling (for all reads and
  multiple writes) to as much as you can afford; 64M on a 256M machine
  that mainly runs MySQL is quite common. If you, however, make this too
  big (for instance more than 50% of your total memory) your system may
  start to page and become extremely slow. Remember that because MySQL
  does not cache data reads, you will have to leave some room for the OS
  filesystem cache. You can check the performance of the key buffer by
  doing show status and examine the variables Key_read_requests,
  Key_reads, Key_write_requests, and Key_writes.

So you should definitely lower the value of key_buffer_size (note the
spelling change - for other variables, too).

I would be suprised if that won't help.



-- 
For technical support contracts, goto https://order.mysql.com/?ref=ma02-010c
This email is sponsored by Ensita.net http://www.ensita.net/
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /    Egor Egorov
 / /|_/ / // /\ \/ /_/ / /__   Egor.Egorov@stripped
/_/  /_/\_, /___/\___\_\___/   MySQL AB / Ensita.net
       <___/   www.mysql.com



Thread
High load with "cleaning up" statusMike Zimmerman12 Oct
  • re: High load with "cleaning up" statusEgor Egorov14 Oct
    • re: High load with "cleaning up" statusMike Zimmerman14 Oct
      • re: re: High load with "cleaning up" statusEgor Egorov16 Oct