I see several values set to '18446744073709551615', which is an
insanely large number for any memory setting (16.7 million terabytes
unless my math is wrong; huge in any case).
There was another person on the list earlier this year who had a
similar problem with large numbers, IIRC. I'd adjust those numbers
down for sure.
Dan
On 12/8/06, Philip Mather <[EMAIL PROTECTED]> wrote:
Kevin Old wrote:
> On 12/8/06, Philip Mather <[EMAIL PROTECTED]> wrote:
>> So something like 15G, that's not that bad. I'd run mtop as someone
>> suggested and see if some query is hammering it, maybe some other
>> process on the machine is hogging or going IO bound?
>
> Thanks. We are watching the queries. The pattern we're seeing now is
> any "large query" that takes more than a few seconds to execute causes
> incoming queries to stack up and not execute, which causes the mysql
> load to go higher. We've seen a few times where mysql recovered after
> a large query started other queries to stack up.
>
> Keep in mind that we've been running some of these queries that are
> now having problems for over a year. We were running on the same
> hardware with the 386 version of mysql and performance was awesome
> only using 2GB RAM (the max mysql would allow us to use). Only after
> the switch to the x86_64 version are we seeing these problems.
Tried an optimize or maybe a myisamchk |--check| or a |--analyze? Might
not be the underlying "cause" but might reduce the occurrences of pile ups?
Maybe there's a hardware issue when using the 64 bit code, any RAID
involved? ||I was vaguely assuming it was a RedHat-a-like box of some
description?|
|
<shrug />
Sounds like some other issue is just pushing MySQL over the edge, not
bumping into any ulimits are you?
Regards,
Phil
|
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
