-
From: "Baron Schwartz" <[EMAIL PROTECTED]>
To: "Justin" <[EMAIL PROTECTED]>
Cc:
Sent: Monday, September 03, 2007 4:42 PM
Subject: Re: servers full potential / FT searches locking tables
Justin wrote:
lockup just happened again.. here's a innodb stat
Justin wrote:
lockup just happened again.. here's a innodb status.
InnoDB status will be basically useless, as full-text is only applicable
to MyISAM, and indeed your status output shows only one transaction is
running (the one running 'show innodb status') and InnoDB has done zero
work sinc
nder if it's something in the mysql config that is lagging
for some reason.
thanks.
- Original Message -
From: "Michael Dykman" <[EMAIL PROTECTED]>
To: "Justin" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, August 28, 2007 1:31 PM
Subject: Re: servers full potenti
- Original Message -
From: "Michael Dykman" <[EMAIL PROTECTED]>
To: "Justin" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, August 28, 2007 1:31 PM
Subject: Re: servers full potential / FT searches locking tables
No, I'm afraid not. 32 bit architectures have
Sorry man, as everyone keeps saying, there is only 4 gig of ram in the
entire known 32 bit universe.. that includes space for
process-specific system buffers, file handles, internals... the
TOTAL amount of ram you can give to 32-bit MySQL in ANY combination is
around 3.5G (many will tell you, not
On Wed, 29 Aug 2007 18:02:31 -0400, "Michael Dykman" <[EMAIL PROTECTED]>
said:
> I mean that the theoretical limit of a 32-bit application is 4G... in
> practice, you won't quite get that (for a pile of practical reasons)..
> best to keep your configured memory requirements to around 3.5G or
> y
I mean that the theoretical limit of a 32-bit application is 4G... in
practice, you won't quite get that (for a pile of practical reasons)..
best to keep your configured memory requirements to around 3.5G or
you will run into weird errors.
- michael dykman
On 8/28/07, Ken Peng <[EMAIL PROTECTE
On Tue, 28 Aug 2007 13:31:43 -0400, "Michael Dykman" <[EMAIL PROTECTED]>
said:
> No, I'm afraid not. 32 bit architectures have a theoretical limit of
> 4G of memory space for the entire application: in actual practice, for
> a variety of reasons too complex to go into here (and are well
> documen
IL PROTECTED]>
Cc:
Sent: Tuesday, August 28, 2007 1:31 PM
Subject: Re: servers full potential / FT searches locking tables
No, I'm afraid not. 32 bit architectures have a theoretical limit of
4G of memory space for the entire application: in actual practice, for
a variety of reasons
t;
> To: "Justin" <[EMAIL PROTECTED]>
> Cc:
> Sent: Tuesday, August 28, 2007 12:51 AM
> Subject: Re: servers full potential / FT searches locking tables
>
>
> > Your settings doesn't seem optimized much.
> >
> > So here first question, do
eu Bruneau" <[EMAIL PROTECTED]>
To: "Justin" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, August 28, 2007 12:51 AM
Subject: Re: servers full potential / FT searches locking tables
Your settings doesn't seem optimized much.
So here first question, do you use 32bits or 64 bi
Your settings doesn't seem optimized much.
So here first question, do you use 32bits or 64 bits platform? If you
have 64 bits platform with 64 bits mysql and os you can boost most the
settings to use almost the 8G of ram you have on the server. If you are
using 32bits you will have to do some
Justin wrote:
Sometimes I get about 300 connections to the server, all are selects
and all select and get the data returned but the connection doesn't go
away and the website doesn't load up.. usually if there is a lock, the
selects wait 2-3 secs and build up, but once unlocked the queries all
x27;s a LAMP backend..
- Original Message -
From: "Jay Pipes" <[EMAIL PROTECTED]>
To: "Rolando Edwards" <[EMAIL PROTECTED]>
Cc: ; "Justin" <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2007 3:03 PM
Subject: Re: servers full potential / FT searches
ql.com
Sent: Monday, August 27, 2007 2:26:29 PM (GMT-0500) America/New_York
Subject: Re: servers full potential / FT searches locking tables
SELECTs don't lock the table. Are you having frequent UPDATEs while
selecting? That would be the reason for locks.
-jay
Justin wrote:
Ok.. Straight
ge -
From: "Jay Pipes" <[EMAIL PROTECTED]>
To: "Justin" <[EMAIL PROTECTED]>
Cc:
Sent: Monday, August 27, 2007 2:26 PM
Subject: Re: servers full potential / FT searches locking tables
SELECTs don't lock the table. Are you having frequent UPDATEs while
s
ment.
Implicit locks are acquired only for the duration of a single statement.
- Original Message -
From: "Jay Pipes" <[EMAIL PROTECTED]>
To: "Justin" <[EMAIL PROTECTED]>
Cc: mysql@lists.mysql.com
Sent: Monday, August 27, 2007 2:26:29 PM (GMT-0500) America/Ne
SELECTs don't lock the table. Are you having frequent UPDATEs while
selecting? That would be the reason for locks.
-jay
Justin wrote:
Ok.. Straight to the point.. Here is what I currently have.
MySQL Ver 14.12 Distrib 5.0.27
RHEL vs 5
584GB Raid 5 storage
8GB of RAM
and Dual 5130 processors
Ok.. Straight to the point.. Here is what I currently have.
MySQL Ver 14.12 Distrib 5.0.27
RHEL vs 5
584GB Raid 5 storage
8GB of RAM
and Dual 5130 processors (2.0GHz Intel Dual-Core Xeon)
what my question is.. is am I utilizing the servers potential with the
following as my settings. The serve
19 matches
Mail list logo
