Hello.


Are you sure that your server doesn't swap? Providing output

of 'SHOW STATUS', 'SHOW VARIABLES' and your table definition

could give more information for suggestions. Also, if you have

a hash index on a MEMORY table that has a high degree of key 

duplication (many index entries containing the same value), 

updates to the table that affect key values and all deletes are 

significantly slower. The degree of slowdown is proportional to the

degree of duplication (or, inversely proportional to the index cardinality).

You can use a BTREE index to avoid this problem.







"Hannes Rohde" <[EMAIL PROTECTED]> wrote:

> Hello everyone,

> 

>        We are using MySQL as the database backend on quite a big portal

> page with about 50.000 users and 3 mio. PIs per day. MySQL is as well =

> the

> backend for the (php) session management. We are using a heap for that =

> case

> as well as for instance phpbb does.=20

> Lately we are experiencing long lasting table locks due to deletes or

> updates on the session table. I know that heap tables only support table

> wide locking, but shouldn't those locks be gone quite fast? I have =

> already

> checked the obvious reasons for this kind of behaviour like swapping but =

> I

> couldn't find anything. Even googling didn't bring anything useful up.

> Hopefully someone got some ideas to solve this problem :-)

> 

> Thank you in advance

> Hannes Rohde

> 

> =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=

> =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF

> incoWEB.de - agentur f=FCr neue medien

> Stapenhorststr. 10

> D-45329 Essen

> 

> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>

> http://www.incoWEB.de

> 

> Phone & Fax 0700-0-4626932

> 0700-0-INCOWEB

> 

> Diese E-Mail enth=E4lt vertrauliche Informationen, die nur f=FCr den =

> o.g.

> Empf=E4nger bestimmt sind! Jede Kenntnisnahme, Verteilung oder

> Vervielf=E4ltigung durch andere Personen ist nicht zul=E4ssig. Sollten =

> Sie diese

> E-Mail irrt=FCmlich erhalten haben, melden Sie uns dies bitte =

> unverz=FCglich.

> 

> This email, its content and any files transmitted with it are intended

> solely for the addressee(s). Access, distribution or copying by any =

> other

> party is not permitted. If you are not the intended recipient, then =

> please

> notify us immediately by returning it to the originator.=20

> 

> 

> 



-- 
For technical support contracts, goto https://order.mysql.com/?ref=ensita
This email is sponsored by Ensita.NET http://www.ensita.net/
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /    Gleb Paharenko
 / /|_/ / // /\ \/ /_/ / /__   [EMAIL PROTECTED]
/_/  /_/\_, /___/\___\_\___/   MySQL AB / Ensita.NET
       <___/   www.mysql.com




-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to