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.
On
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 server are
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:
snip
If the value of this variable is positive, the MySQL server synchronizes its
binary log to disk
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
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 words,
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: Almar van Pel
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
@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 case of not having the cardinality
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 incorrect
-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 fatene'
Subject: Re: Performance issues
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 file,
to:
06/28/2004 02:24 Subject: Re: Performance issues
PM
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: Performance issues
On Tue, Jun 22, 2004 at 01:34:39PM -0400, Aram
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
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
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
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
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 makes
ay, 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
this is what I came up with...
The Key_reads/Key_read_reque
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
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
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: Performance issues.
Thanks
'; [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 start of the string is unknown.
The index will only be used if the server decides
"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
24 matches
Mail list logo
