Hello,
I reached a point I can't go any further with forcing mysql to use the
index as much as needed. I am facing a multi column index of which only
the first column is used.
Let me explain...
This works fine:
create table A ( a mediumint not null, b date not null, index (a,b));
Populate the
Two small corrections:
ad point 1.
b in ('2004-05-01') behaves different from b = '2004-05-01'. The
last one is better: key_len = 6, instead of 3.
mysql explain select count(*) from A, B where A.a=B.a and b ='2004-05-01';
in time to stop mysqld.
So, there is another thing than the smp bug as you described !
I'll try mysql 3.22 and I will keep you informed.
Regards,
Herald
Sinisa Milivojevic wrote:
Herald van der Breggen writes:
Hello Noor,
I am struggling with a similar problem on a linux based system
Does a downgrade to MySQL 3.22.x help ? (seems less work to me, but I'l
investigate the other possibilities anyway).
Sinisa Milivojevic wrote:
Herald van der Breggen writes:
Hello Noor,
I am struggling with a similar problem on a linux based system. It's a
Netfinity 4500R, dual
Sinisa Milivojevic wrote:
Hi!
The above is an already reported problem that occurs only on SMP Linux
on the high load.
A solution is to try kernel 2.4, glibc 2.2 (when stable) and to build
properly MySQL on that setup.
Regards,
Sinisa
Do you know whether the problem is
Hello Noor,
I am struggling with a similar problem on a linux based system. It's a
Netfinity 4500R, dual pentium, RAID-5 with a rather new ServeRaid-4L
scsi controler.
On certain moments, mostly in the peak hours, mysql suddenly behaves
weird and the load increases very very quick. The swap
Good question.
I can give you some details about the database I am using. This is about
another situation than Noor's (linux instead of FreeBSD), but the
problems looks similar.
I have not find any specific event that causes mysqld spinning around
and claiming memory. I activited the logging
I hope so.
A point that my Noor's situation and mine have in common is fast disks.
Maybe there is a timeng problem ?
Another remarkeble table I did not mention is a table with a blob-field.
The blob field is used to store perl-objects with a size of about 8Kb.
The table is about 3000 rows
in
version 3.23.30 ?
2. Is the GET_LOCK-mechanism the most suitable one to use with
Apache::Session ?
3. Do you have any idea's what the problem could be or how to
investigate or how to solve ?
Thanks !
Herald van der Breggen
P.S. I upgraded today to version 3.23.31, so far
