Hi Guys
I am once again having a weird issue... well weird to me anyway.
We have a master,slave setup using mysql 5.7 and they are both
connected on the same network segment through the same switch.
During the weekend a HUGE amount of processing was done on the master,
and thus resulted
h with a connection to the MySQL server, to insert rows into the
> same table. Totally 3200 rows are inserted into the table.
>
> When I try to vary the number of C# threads I found that the time
> taken to finish the benchmark decreases, thus increasing the
> throughput. The through
number of C# threads I found that the time
taken to finish the benchmark decreases, thus increasing the
throughput. The throughput increases almost linearly with the number
of C# threads, until I reach 100 threads, which is the maximum number
of connections allowed by my server.
This is quite
Are there any publicly available data on how the size of some (or better
yet, many) particular "real" database(s) changed over time (for a longish
period of time)? How about data on how the throughput (in any interesting
terms) varied over time?
Thanks,
Mike Spreitzer
I've added a fair bit of information on the Opteron HOWTO Wiki at:
http://hashmysql.org/index.php?title=Opteron_HOWTO
for using Fedora Core 3 with X86-64.
In my performance testing, I was finding that with so much RAM, everything
was coming from RAM anyway. RAID10 seemed to be most stable, and wr
On Sat, 2005-05-07 at 08:18, Greg Whalin wrote:
> Hi Peter,
>
> As for reporting bugs ...
> http://bugs.mysql.com/bug.php?id=7437
> http://bugs.mysql.com/bug.php?id=10437
>
> We have found Opteron w/ Mysql to be an extremely buggy platform,
> especially under linux 2.6, but granted, we are runni
Greg Whalin wrote:
Curious, were you seeing deadlocks in Suns JVM w/ Tomcat?
Never with Tomcat but we might have a different number of threads. But
it *was* with Java...
We were forced to run Tomcat w/ NPTL off due to deadlocks under glibc
2.3.2+NPTL.
Yup.. thats the problem we had. But we h
Kevin Burton wrote:
Greg Whalin wrote:
We are currently running 2.3.2 (Fedora Core 1) on our Opterons. When
we were still running linux 2.6, we were on 2.3.3 (Fedora Core 2).
Yeah... we were being bitten by 2.3.2's NPTL implementation for MONTHs
before I heard a rumor that the Internet Archive
Greg Whalin wrote:
We are currently running 2.3.2 (Fedora Core 1) on our Opterons. When
we were still running linux 2.6, we were on 2.3.3 (Fedora Core 2).
Yeah... we were being bitten by 2.3.2's NPTL implementation for MONTHs
before I heard a rumor that the Internet Archive moved to 2.3.4.
Thi
Kevin Burton wrote:
Greg Whalin wrote:
I suspect this is an OS issue. Our Opteron's were completing large
data update queries aprox 2-3 times slower than our Xeons when running
under 2.6. After a switch to 2.4, Opteron's are faster than the
Xeons. I mentioned NPTL being shut off (LD_ASSUME_KE
Greg Whalin wrote:
I suspect this is an OS issue. Our Opteron's were completing large
data update queries aprox 2-3 times slower than our Xeons when running
under 2.6. After a switch to 2.4, Opteron's are faster than the
Xeons. I mentioned NPTL being shut off (LD_ASSUME_KERNEL=2.4.19 in
init
In the last episode (May 07), Atle Veka said:
> On Fri, 6 May 2005, Kevin Burton wrote:
> > For the record... no a loaded system what type of IO do you guys
> > see? Anywhere near full disk capacity? I'm curious to see what
> > type of IO people are seeing on a production/loaded mysql box.
>
> Mo
On Sat, 7 May 2005, Kevin Burton wrote:
> It looks like you're saying here that a single disk is FASTER than your
> RAID 10 setup.
>
> Correct?
>
> Which is interesting. I'm wondering if this is a RAID config issue. It
> just seems to make a LOT more sense that RAID 1 or 10 would be faster
> tha
Atle Veka wrote:
On Fri, 6 May 2005, Kevin Burton wrote:
For the record... no a loaded system what type of IO do you guys see?
Anywhere near full disk capacity? I'm curious to see what type of IO
people are seeing on a production/loaded mysql box.
Mostly Linux in this thread so far, so I f
On Fri, 6 May 2005, Kevin Burton wrote:
> For the record... no a loaded system what type of IO do you guys see?
> Anywhere near full disk capacity? I'm curious to see what type of IO
> people are seeing on a production/loaded mysql box.
Mostly Linux in this thread so far, so I figured I'd throw
Hi Peter,
As for reporting bugs ...
http://bugs.mysql.com/bug.php?id=7437
http://bugs.mysql.com/bug.php?id=10437
We have found Opteron w/ Mysql to be an extremely buggy platform,
especially under linux 2.6, but granted, we are running Fedora. Perhaps
we will try Suse, but I feel I have heard sim
On Fri, 2005-05-06 at 19:01, Greg Whalin wrote:
> What drives are you using? For SCSI RAID, you definitly want deadline
> scheduler. That said, even after the switch to deadline, we saw our
> Opteron's running way slow (compared to older slower Xeons). Whatever
> the problem is, we fought it
gt;
>
> I know of a site that encountered a similar performance issue:
> The OS was reading in a lot more data from the disk than the
> database really needed.
>
> The culprit turned out to be the stripe size on a 4-disk RAID.
> By reducing the stripe size from 768K to 32K,
a from the disk than the
database really needed.
The culprit turned out to be the stripe size on a 4-disk RAID.
By reducing the stripe size from 768K to 32K, they obtained a
200% increase in mysql throughput.
- JD
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsub
t; Device:rrqm/s wrqm/s r/s w/s rsec/s wsec/srkB/swkB/s
> avgrq-sz avgqu-sz await svctm %util
> sda0.00 13.73 128.43 252.94 1027.45 1695.10 513.73847.55
> 7.1490.13 285.00 2.53 96.57
>
> This is only seeing about 500k -> 1M per s
Greg Whalin wrote:
What drives are you using? For SCSI RAID, you definitly want deadline
scheduler. That said, even after the switch to deadline, we saw our
Opteron's running way slow (compared to older slower Xeons). Whatever
the problem is, we fought it for quite a while (though difficult t
What drives are you using? For SCSI RAID, you definitly want deadline
scheduler. That said, even after the switch to deadline, we saw our
Opteron's running way slow (compared to older slower Xeons). Whatever
the problem is, we fought it for quite a while (though difficult to test
too much w/
Kevin Burton wrote:
Greg Whalin wrote:
Deadline was much faster. Using sysbench:
test:
sysbench --num-threads=16 --test=fileio --file-total-size=20G
--file-test-mode=rndrw run
So... FYI. I rebooted with elevator=deadline as a kernel param.
db2:~# cat /sys/block/sda/queue/scheduler
noop anticipa
Greg Whalin wrote:
Deadline was much faster. Using sysbench:
test:
sysbench --num-threads=16 --test=fileio --file-total-size=20G
--file-test-mode=rndrw run
Wow... what version of sysbench are you running? Its giving me strange
errors
sysbench v0.3.4: multi-threaded system evaluation
Kevin Burton wrote:
Greg Whalin wrote:
We have seen the exact same thing here. We used the deadline
scheduler and saw an immediate improvement. However, we still saw
much worse performance on our Opteron's (compared to our older Xeon
boxes). We ended up rolling back to Fedora Core 1
2.4.22-1
Greg Whalin wrote:
We have seen the exact same thing here. We used the deadline
scheduler and saw an immediate improvement. However, we still saw
much worse performance on our Opteron's (compared to our older Xeon
boxes). We ended up rolling back to Fedora Core 1
2.4.22-1.2199.nptlsmp kernel
om
Subject: MySQL not using optimum disk throughput.
We have a few of DBs which aren't using disk IO to optimum capacity.
They're running at a load of 1.5 or so with a high workload
of pending queries.
When I do iostat I'm not noticing much IO :
Device:rrqm/s wrqm/s r/s w/s
age-
> From: Kevin Burton [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 06, 2005 1:58 PM
> To: mysql@lists.mysql.com
> Subject: MySQL not using optimum disk throughput.
>
>
> We have a few of DBs which aren't using disk IO to optimum capacity.
>
> They're ru
vgqu-sz await svctm %util
sda 0.00 13.73 128.43 252.94 1027.45 1695.10 513.73
847.55 7.1490.13 285.00 2.53 96.57
...
This is only seeing about 500k -> 1M per second throughput.
When I run bonnie++ on these drives they're showing 20M->40M throughput.
Which is r
Hi!
> "Emmanuel" == Emmanuel van der Meulen <[EMAIL PROTECTED]> writes:
Emmanuel> Hello Monty,
Emmanuel> With your help I'm getting the understanding I was looking for, thank you.
>> Note however that if there would have been less matching rows (for
>> example 60), the SQL_CALC_FOUND_ROW
Hello Monty,
With your help I'm getting the understanding I was looking for, thank you.
On 27 January 2002 23:23, Michael Widenius wrote;
> Hi!
>
> > "Emmanuel" == Emmanuel van der Meulen <[EMAIL PROTECTED]> writes:
>
>
>
> >> This will of course slow down any query significantly, if the
Hi!
> "Emmanuel" == Emmanuel van der Meulen <[EMAIL PROTECTED]> writes:
>> This will of course slow down any query significantly, if the WHERE
>> clause matches a lot of rows, but should still be faster than:
>>
>> - retrieving all rows to get a count.
>> or
>> - Do two queries:
>> SELEC
Emmanuel van der Meulen writes:
> Hello Monty,
>
> I downloaded and installed 4.0.1 for the SQL_CALC_FOUND_ROW option.
> However, the query runs 600% longer, so the saving I get with FOUND_ROWS()
> running in 0.0 secs does not serve me. Am I maybe doing something wrong?
>
> Here is what I did;
rds
Emmanuel
> -Original Message-
> From: Michael Widenius [mailto:[EMAIL PROTECTED]]
> Sent: 21 January 2002 00:44
> To: Emmanuel van der Meulen
> Cc: MySQL General List; MySQL Java List
> Subject: RE: Understanding throughput with JDBC
>
>
>
> Hi!
>
ROTECTED]]
> Sent: 21 January 2002 00:44
> To: Emmanuel van der Meulen
> Cc: MySQL General List; MySQL Java List
> Subject: RE: Understanding throughput with JDBC
>
>
>
> Hi!
>
> >>>>> "Emmanuel" == Emmanuel van der Meulen <[EMAIL PROTECTED]>
Hi!
> "Emmanuel" == Emmanuel van der Meulen <[EMAIL PROTECTED]> writes:
Emmanuel> Hello Mark,
Emmanuel> Thank you for the note and feedback. BTW, it was not over a network. Both
Emmanuel> on local PC. So all the time went into building the resultset in memory.
Emmanuel> I'm surprised at
ED]>; "Nick" <[EMAIL PROTECTED]>
Sent: Sunday, January 20, 2002 12:46 PM
Subject: RE: [OT] Re: Understanding throughput with JDBC
> Hello Nick,
>
> Does ROWNUM exist in MySQL?
>
> Kind reagrds
> Emmanuel
>
> > -Original Message-
> > From: Ni
Hello Dave,
Thank you. This works.
Kind regards
Emmanuel
> -Original Message-
> From: Adrian Monea [mailto:[EMAIL PROTECTED]]
> Sent: 20 January 2002 15:08
> To: 'Emmanuel van der Meulen'
> Cc: [EMAIL PROTECTED]
> Subject: RE: Understanding throughput with
Hello Nick,
Does ROWNUM exist in MySQL?
Kind reagrds
Emmanuel
> -Original Message-
> From: Nick [mailto:[EMAIL PROTECTED]]
> Sent: 19 January 2002 20:41
> To: Shankar Unni
> Cc: [EMAIL PROTECTED]
> Subject: [OT] Re: Understanding throughput with JDBC
>
>
>
Mark Robson [mailto:[EMAIL PROTECTED]]
> Sent: 19 January 2002 16:49
> To: MySQL Java List
> Subject: Re: Understanding throughput with JDBC
>
>
> > B. When running the exact same select as stated above in a java program
> > using JDBC, from when issuing, ResultSet rs
rom: Mark Matthews [mailto:[EMAIL PROTECTED]]
> Sent: 19 January 2002 16:25
> To: Emmanuel van der Meulen
> Cc: [EMAIL PROTECTED]
> Subject: Re: Understanding throughput with JDBC
>
>
>
> - Original Message -
> From: "Emmanuel van der Meulen" <[EMAIL PROTE
Hello all,
Could anyone please assist me to understand this. I want to understand
where the time is going to and whether there is something I can do about it,
with the following query when using JDBC;
Here is the table declaration;
CREATE TABLE Memberships ("EMAIL CHAR(60) NOT NULL,
On Thu, Oct 18, 2001 at 08:02:04PM -0700, Bob Farnworth wrote:
>
> I am looking for some information on throughput (I.E. transactions
> per second) for MySQL. Anyone have some or some suggestions? I
> realize there is no hardware listed.
You've given no specifics, so he
Hi Bob,
> I am looking for some information on throughput
> (I.E. transactions per second) for MySQL.
> Anyone have some or some suggestions?
> I realize there is no hardware listed.
Nor anything else ;-)
Performance also depends on your database, type of query, etc.
Generally spe
I am looking for some information on throughput (I.E. transactions per second) for
MySQL. Anyone have some or some suggestions? I realize there is no hardware listed.
Bob Farnworth
Find the best deals on the web at AltaVista Shopping!
http://www.shopping.altavista.com
45 matches
Mail list logo
