It should be basically almost only IO that limits in that case.
First of all have you compared the ini files between the AMD and the other servers to see if there is any difference?
What kind of disk setup do you have in the different machines?
Do you read the 50Gb file that you are importing from the same disk as your databases are located on?
Are they all the same type of OS?
Because I can tell you that this has nothing to do with if it’s an AMD or an Intel CPU in the box.
This is about what disks you have, how they are setup, what cache is activated, how much RAM you have available for OS cache etc.
It should be basically almost only IO that limits in that case.
First of all have you compared the ini files between the AMD and the other servers to see if there is any difference?
What kind of disk setup do you have in the different machines?
Do you read the 50Gb file that you are importing from the same disk as your databases are located on?
Are they all the same type of OS?
Because I can tell you that this has nothing to do with if it’s an AMD or an Intel CPU in the box.
This is about what disks you have, how they are setup, what cache is activated, how much RAM you have available for OS cache etc.
It is clear that IO is the reason.
I am sorry about DB size - it’s 50MB not GB.
But the question is: why a performance degradation take place on Intel PC but not happens on AMD PC with the same MySQL settings.
AMD developer machine: OS: Windows XP 32 SP2 MB: Epox NVidia NForce 3 CPU: AMD Athlon 64 3000+ Drive: Seagate Barracuda EIDE ATA-100, 7200 RPM, 8MB
Single hard drive
Intel developer machine: OS: Windows XP 32 SP2 MB: MSI P965 NEO, Intel P965 CPU: Intel Core 2 6400 2.13 GHz Drive: WD Caviar SE16. SATA, 400 GB, 16 MB Cache, 7200 RPM, 300 MB/s
Single hard drive connected through JMicron JMB36x RAID Controller as sole way of using hard drive with Intel P965 mother board logic.
HP Intel Xeon server: OS: Windows 2003 Standard Server R2 CPU: 2 x Xeon 3.00 GHz Drive: HP Smart Array 6i (RAID 5)
I’ve tried same default my.ini on all machines as well as custom tuned my.ini’s - no diffrence.
MySQL: 5.1.12-beta
Restoration methods:
With MySQL Administrator (from mysql-gui-tools-5.0-r9a-win32.msi)
By command: mysql -hlocalhost -u%dbuser% -p%passw% %dbname% backup_file.sql
With the same MySQL configuration Intel machine 30 times slower as against AMD.
AMD machine: High IO load with 40-60% CPU utilization
Intel machines: High IO load with 2-4% CPU utilization
If that is set to default 1 it means that the transaction log needs to be flushed to disk after each transaction. And if you are running in autocommit mode then every statement is a transaction.
And basically a disk actually only supports about 167 flushes per second:
[B]Quote:[/B]
Wrap several modifications into one transaction. InnoDB must flush the log to disk at each transaction commit if that transaction made modifications to the database. The rotation speed of a disk is typically at most 167 revolutions/second, which constrains the number of commits to the same 167th of a second if the disk does not “fool” the operating system.
So if your disk on the AMD is reporting that it has written it to disk although it only has stored it in cache.
While your Intel machines is waiting for the writing to actually occure it would give two very different figures for speed.
BTW do you have a write cache on the HP RAID installed?
Also:
[B]Quote:[/B]
When importing data into InnoDB, make sure that MySQL does not have autocommit mode enabled because that requires a log flush to disk for every insert. To disable autocommit during your import operation, surround it with SET AUTOCOMMIT and COMMIT statements:
SET AUTOCOMMIT=0;
… SQL import statements …
COMMIT;
If you use the mysqldump option --opt, you get dump files that are fast to import into an InnoDB table, even without wrapping them with the SET AUTOCOMMIT and COMMIT statements.
I just wanted to let you know that aside from being a MySQL demi-God, you are a gentleman and a scholar. Your suggestion here has fixed a slow update problem that has been driving me bananas for two years now (the performance issue was only showing up on some of my servers).
