Bug #10939 | set type=(type+0)|(1<<3),type=(type+0)&~(1<<2) = CS>70000 | ||
---|---|---|---|
Submitted: | 28 May 2005 13:20 | Modified: | 2 Feb 2006 12:08 |
Reporter: | Sergey Frolovichev | Email Updates: | |
Status: | No Feedback | Impact on me: | |
Category: | MySQL Server | Severity: | S3 (Non-critical) |
Version: | 4.1.12 | OS: | Linux (SuSe 9.3) |
Assigned to: | Assigned Account | CPU Architecture: | Any |
[28 May 2005 13:20]
Sergey Frolovichev
[28 May 2005 13:34]
Heikki Tuuri
Sergey, can you make a small test case with a much simpler table definition that demonstrates this performance problem? Why do you update the column 'type' twice in the same UPDATE? What does SHOW INNODB STATUS show during the high load? Regards, Heikki
[28 May 2005 13:39]
Sergey Frolovichev
Will be today in the evening! Now I'm removing collation specification for column type. Twice it is specifield because of specific of application (it collects double updates to one but only in this manner - if an error will be in this - I can fix it quickly)
[28 May 2005 15:13]
Sergey Frolovichev
Hi! I have made very easy test now ;-) Here comes create for table: =================== CREATE TABLE `Anketa` ( `oid` int(10) unsigned NOT NULL default '0', `type` set('PreModeration','Intim','LeaderTry','Leader','Banned','VoiceForward','VoiceWelcome','K') character set utf8 NOT NULL default '', `created` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, PRIMARY KEY (`oid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci =================== Here comes very simple php code which simply replaces 10.000.000 records in this table, and I have started it in background and have run "vmstat 1" on my machine it's about 70.000 CS... =================== <? set_time_limit(0); $dbcon=mysql_connect("localhost","root",""); if ($dbcon) { for ($i=0;$i<1000000;$i++) { $ins="replace into Anketa.Anketa (oid,type,created) values (".$i.",'',now())"; $inse=mysql_query($ins,$dbcon); } } ?> ===================
[29 May 2005 5:22]
Peter Zaitsev
I've look into this case. The problem seems to be general - even simple table with single auto_increment column shows the same problem. Number of context switches is proporsional to number of queries/sec and is 8-10 context switches per query. On my box I get 4 context switches per query in the same case, running test on the same box as MySQL server. This corresponds to my experiments a while back so there is no regressions here. This number is also same for MyISAM and Innodb tables. Number 8-10 could be due to the fact self-compiled binary is used (NPTL ?) or due to usage of multi CPU box - I tested on single CPU box It would be great to give standard MySQL binary a try to see if problem still persists. In general I would not call it a bug, but rather performance suboptimality. Modern Linux systems can do other 1.000.000 context switches/sec so context switching in this case should only take a portion of system resources. If performance of this query is seriously less than expected it should be analyzed separately.
[29 May 2005 7:34]
Heikki Tuuri
Changing the Category to MySQL Server, because the phenomenon of 2 times more context switches than necessary is also for MyISAM. If you do REPLACES, then InnoDB's purge thread will also run, but I do not see how it could cause more than a couple of context switches per second. Also I recall seeing the excessive context switches in Linux a few years ago. Regards, Heikki
[29 May 2005 7:38]
Sergey Frolovichev
I have got the same problem after downloading and installing 4.0, 4.1.11, 4.1.12. This test was on clean mashine without any other load. Mashine: Intel SR1300, Dual Xeon, 4Gb RAM, 2x140Gb 10K RPM, RAID 1.
[29 May 2005 8:23]
Sergey Frolovichev
I have tested 4.0, 4.1.12 RPM on single CPU Xeon. 4.0: 62.000CS per second. So it is about 8 cs per query on 1000000 replaces (~130 sec) to single field primary key table. 4.1.12rpm: 83.000 CS per second. So it is about 7.5 cs per quesry on 1000000 replaces (~89 sec) to single field primary table. Also I want to add more info - operating system is SuSe Linux 9.1 (on the 32 bit mashines) and kernel version is 2.4.28 PS: On 2.6 kernel mysql hangs whole machine like it was few seconds ago working and now is gone - only reset helps :-( It happens usualy in 24 hours from start without any information in logs, system logs, SA and other special logs systems which we tryed to use. This happens with load or without any load on mysql server.
[29 May 2005 21:39]
Heikki Tuuri
Sergey, in which 2.6 distro does the hang happen? --Heikki
[30 May 2005 13:03]
Sergey Frolovichev
2.6.5-0- #7 SMP Mon Apr 25 06:35:11
[7 Sep 2005 9:18]
Vadim Tkachenko
I'm able to repeat it on SUSE LINUX Enterprise Server 9 (x86_64), 2x Opteron 1.6Ghz. (Linux 2.6.5-7.97-smp). I observe big cs even with MyISAM table: CREATE TABLE `Anketa` ( `oid` int(10) unsigned NOT NULL default '0', `type` VARCHAR(12) NOT NULL default '', `created` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, PRIMARY KEY (`oid`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
[7 Sep 2005 9:30]
Vadim Tkachenko
Solaris 10 / SPARC - stable CS = 23475
[2 Jan 2006 12:08]
Konstantin Osipov
Sergey, could you please try to check whether priority adjustments performed by MySQL server throughout execution of a query are of any harm in your case. I expect the overall amount of context switches to decrease once these adjustments are removed - they are mostly relevant for long-running queries or many threads with low per-thread load (but high overall load). To disable priority modifications during execution of a query, please apply the following patch: kostja@oak:~/mysql/mysql-4.1-root/sql> bk diffs -u ===== init.cc 1.15 vs edited ===== --- 1.15/sql/init.cc 2004-04-07 05:33:56 +04:00 +++ edited/init.cc 2006-01-02 15:07:34 +03:00 @@ -46,5 +46,6 @@ log_10[i]= nr ; nr*= 10.0; } specialflag|=options; /* Set options from argv */ + specialflag|= SPECIAL_NO_PRIOR; DBUG_VOID_RETURN; } Vadim: you could give this patch a try as well. Thanks! Thanks!
[20 Jan 2006 11:11]
Vadim Tkachenko
I testes with 5.0.18. I tried specialflag=SPECIAL_SAME_DB_NAME | options; /* Set options from argv */ specialflag|=SPECIAL_NO_PRIOR; /* Set options from argv */ in sql/init.cc. It does not help, CS = 38000 on quadxeon box.
[3 Feb 2006 0:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".