Thanks Ravi
On Tue, 2006-04-11 at 11:41 +0530, Ravi Prasad LR wrote:
> yes, that is the reason for slowness .
>
> Thanks,
> Ravi
> On Tuesday 11 April 2006 10:51, Mohammed Abdul Azeem wrote:
> > Hi Ravi,
> >
> > Since the sync'ing is done to disk with sync_binlog=1, the update
> > queries to se
yes, that is the reason for slowness .
Thanks,
Ravi
On Tuesday 11 April 2006 10:51, Mohammed Abdul Azeem wrote:
> Hi Ravi,
>
> Since the sync'ing is done to disk with sync_binlog=1, the update
> queries to server are slower compared to the server having sync_binlog=0
> rite ?
>
> Thanks,
> Abdul
Hi Ravi,
Since the sync'ing is done to disk with sync_binlog=1, the update
queries to server are slower compared to the server having sync_binlog=0
rite ?
Thanks,
Abdul.
On Tue, 2006-04-11 at 10:51 +0530, Ravi Prasad LR wrote:
> Hi Abdul,
>When sync_binlog is set to 1, innodb
Hi Abdul,
When sync_binlog is set to 1, innodb fsyncs the binary log to
disk after every single write to binary log, but not in the case of
sync_binlog=0.
From MySQL manual:
If the value of this variable is positive, the MySQL server synchronizes its
binary log to disk (fdatas
ces/articles/mysql-set-datatype.html.
Massive load is better without indexes, which are only good for selects.
Mathias
-Original Message-
From: Jigal van Hemert [mailto:[EMAIL PROTECTED]
Sent: dimanche 24 avril 2005 19:46
To: Almar van Pel; mysql@lists.mysql.com
Cc: 'mathias faten
> > It's a probably a case of not having the cardinality of indexes right
and
> thus making wrong decisions for queries.
> - Currently there is not a single query in the application that does not
use
> the correct index. We only have key-reads. Wich would mean that MySQL is
> creating these incorre
sql@lists.mysql.com
Cc: 'Jigal van Hemert'; 'mathias fatene'
Subject: RE: Performance issues when deleting and reading on large table
Hi Jigal, Mathias,
Thanks the time you took to reply to my issue's!
I would like to clear out some things.
> It's a probably a c
Hi Jigal, Mathias,
Thanks the time you took to reply to my issue's!
I would like to clear out some things.
> It's a probably a case of not having the cardinality of indexes right and
thus making wrong decisions for queries.
- Currently there is not a single query in the application that does n
k using or
not of internal temporary tables, ...
Mathias
-Original Message-
From: Jigal van Hemert [mailto:[EMAIL PROTECTED]
Sent: dimanche 24 avril 2005 17:05
To: Almar van Pel; mysql@lists.mysql.com
Subject: Re: Performance issues when deleting and reading on large table
From: &quo
From: "Almar van Pel"
> After some time (sometimes a week sometimes a month) it appears that the
> index of the table gets stuck.
> It tries to read from the table but does not get response. This causes the
> connectionqueue to fill up
> and the load on the system increases dramatically. In other
On Mon, Jun 28, 2004 at 09:21:04PM +0100, Andrew Pattison wrote:
> By default MySQL flushes keys to disk with every INSERT, hence the
> performance degredation with performing several single INSERTs one after the
> other. The following extract from the MySQL documentation hints at one way
> of chan
asis but I couldn't find a quick reference to that.
Cheers
Andrew.
- Original Message -
From: "Jeremy Zawodny" <[EMAIL PROTECTED]>
To: "Aram Mirzadeh" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, June 28, 2004 7:24 PM
Subject: Re: Perf
;
om> cc: [EMAIL PROTECTED]
Fax to:
06/28/2004
On Tue, Jun 22, 2004 at 01:34:39PM -0400, Aram Mirzadeh wrote:
>
> We have an internal SNMP monitoring system that is monitoring about
> 10,000 devices. Each device is pinged then pulled for about an
> average of 25-30 elements. Each of the ping results and elements
> are then stored in text fil
At 12:34 PM 6/22/2004, you wrote:
We have an internal SNMP monitoring system that is monitoring about 10,000
devices. Each device is pinged then pulled for about an average of 25-30
elements. Each of the ping results and elements are then stored in text
file, then another system picks them up
Hi!
Can you give more details on the problematic inserts you're doing (table
structure, indexes and insert command) ?
Also, do you believe your queries would benefit from MySQL's query cache?
Maybe it's worth upgrading to version 4 and use this feature, even if
you allocate just a small amount
Have you checked the network connection? You should be running at
full-duplex so you don't get collisions. But more importantly, make sure you
aren't getting errors on the line. A poor crimp or pinched wire could really
slow things down, especially if you try running at 100MB.
Try copying a single
Hi.
On Wed, Feb 07, 2001 at 03:01:28PM -0500, [EMAIL PROTECTED] wrote:
[...]
> We have one table with all the defintions on it's own row.
> Then we have built off of that table another table that is only the distinct
> words, no definitions.
>
> This is because if a word has 10 definitions, it m
MYISAM
improved performance. As well as doing maintenance on each table with
myisamchk.
Thanks again,
Ryan
-Original Message-
From: Ryan Hadley [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 07, 2001 3:01 PM
To: [EMAIL PROTECTED]
Subject: RE: Performance issues.
Maybe we're
rom: Jason Terry [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 07, 2001 11:01 AM
To: Jim Beigel; [EMAIL PROTECTED]
Subject: Re: Performance issues.
Cool, I like this info. (especially key_buffer_size stuff)
However, I was running my numbers against what you said would be good. And
gt;
Sent: Wednesday, February 07, 2001 6:32 AM
Subject: RE: Performance issues.
> Ryan:
>
> 1.) ...WHERE word LIKE '%word%' will never be fast.
>
> 2.) Since you said you have indexed the field, if you can limit your
> searches to ...WHERE word LIKE 'word%'
Tuesday, February 06, 2001 6:09 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Performance issues.
>
>
> Thanks for the quick response.
>
> The response time is slow... and the mysqld processes are what is
> hogging up
> the system.
>
> We do have indexes on the fields, but from
"Only" 272235??? I enter on average about 75,000 to 80,000 records a day
(and some times, I break 100,000 records a day. I do monthly rotations so
it's easy to calculate how big my table gets). Granted, I don't know what
your table structure is but mine is very simple. All I do is run impor
uesday, February 06, 2001 7:26 PM
To: 'Ryan Hadley'; [EMAIL PROTECTED]
Subject: RE: Performance issues.
Hi,
For an indexed column, the index is used if the start of the string is used:
LIKE 'a string of text%' may use an index
LIKE '%any old string%' will not, since the st
er
than a full table scan.
Have you got the results of 'explain select ' to see if your index is
actually being used.
Regards
Quentin
-Original Message-
From: Ryan Hadley [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 7 February 2001 12:09
To: [EMAIL PROTECTED]
Subject: RE: Perfor
Thanks for the quick response.
The response time is slow... and the mysqld processes are what is hogging up
the system.
We do have indexes on the fields, but from what I understand, when you use a
"LIKE" statement, it rarely uses an index.
-Ryan
-Original Message-
From: Kent Hoover [ma
Woah! 800,000 visits a day!? Wow... try 80,000.
-Original Message-
From: Ryan Hadley [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 06, 2001 5:25 PM
To: [EMAIL PROTECTED]
Subject: Performance issues.
I'm not much of a db admin so I really don't know how to get better
performance
27 matches
Mail list logo
