Ok, You have 2 core pairs, each pair use shared cache space. Active process on the first core in pair use almost all cache space. The second core (from this pair, of course) have advantage, if working processes migrate between this two cores ONLY. Good for Core DUO in SMP model (one core execute OS process, the other one - SQL server, for example, then this processes migrates from one core to other - cache content and hits are practically the same). If 2 independent, active using cache processes, with different address spaces (and cache "content") using 2 cores in the same pair, it's *not* good. In common, to use multi Intel Core Quad server effectively, one must plan process migration between not only cores, but pairs of cores. Or use not Intel processors, with independent level 2 cache for each core. Or use only 1 working process... 5 efficient processes for 4*Intel Core Quad processor server looks like 1 "header" and 4 "working" processes - 1 process per 1 processor (not per 1 core).
Date: Thu, 21 Aug 2008 20:49:03 +1000From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Re: [Dbmail] Query to show mailbox folders running slow I don't see a down side to a shared L2 cache for big SMP boxes?Given that anything running on that many cores (ie dbmail) is probably going to have a bunch of processes/threads that are all basically identical only keeping one copy of the data floating around seems to be an advantage, you can then fit more data into your (bigger) l2 cache.Vladimir Likhachev wrote: If it`s INTEL Quad-Core processors, cores are not independent. Includes 2 core pairs, each pair using common level 2 cache - good for Windows desktop applications only, I think.It`s a common view only, not detailed analyse.Moreover, Em64T Intel tehnology is a strange one, if more then 4 GB RAM installed.Oracle (current owner of MySQL AB) suggests AMD64 processors. Forgive me poor English and possible oftopic, please... Date: Wed, 20 Aug 2008 09:46:55 -0500From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Re: [Dbmail] Query to show mailbox folders running slow It turns out the problem is related to a well documented issue with mulit-core processors and MySQL running INNODB. We had to drop the thread concurrency to 1 in MySQL to get our load tests to finish properly. The low thread concurrency unfortunately causes issues when it comes to syncing off our existing system onto the new dbmail system; our times went from 8 hrs to over 15 hrs using IMAPSYNC. Through some trial and error, we determined that for optimal syncing, thread concurrency needs to be set at 5 and for standard use thread concurrency needs to be set to 1.Here are some links documenting the Multi-Core Innodb MySQL issue.http://www.bigdbahead.com/?p=59http://mysqlguy.net/blog/2008/07/16/innodb-multi-core-performancehttp://www.anandtech.com/IT/showdoc.aspx?i=2772&p=9Unfortunately we didn't know this when we bought our 4XQuad-Core Server (16 cores).Thanks,Rob On Wed, Aug 20, 2008 at 7:38 AM, Paul J Stevens <[EMAIL PROTECTED]> wrote: My guess is this is a table-locking issue, something you can easily determine bylooking at mytop or 'mysqladmin processlist' during the slowdown. I can notcomment on your parameters since I don't know what kind of resources the mysqlserver has. David Suehring wrote:> Hey everybody,>> We are running into a few issues when running some load tests on dbmail.> As we are running the test, I've noticed that the following query goes> from running nearly instantly, to taking anywhere from 10-20 seconds:>> SELECT distinct(mbx.name <http://mbx.name>), mbx.mailbox_idnr, > mbx.owner_idnr FROM dbmail_mailboxes mbx LEFT JOIN dbmail_acl acl ON> > mbx.mailbox_idnr = acl.mailbox_id> LEFT JOIN dbmail_users usr ON acl.user_id > = usr.user_idnr WHERE> ((mbx.owner_idnr = 2676) OR (acl.user_id = 2676 AND > acl.lookup_flag => 1) OR (usr.userid = 'anyone' AND acl.lookup_flag = 1))>> > As far as our setup goes, we are using dbmail 2.2.10 with MySQL 5.0.26.> > <http://5.0.26.> Our dbmail_mailboxes table currently has about 47000 > rows, dbmail_users has about 4000 rows, and dbmail_acl has 0 rows. The> load > test we are doing uses a web interface to connect to dbmail, read a> message, > send a message, and repeat. When we simulate 10 users doing> this, we do not > see any performance issues. Once we increase to 20> users, the query above > begins to take longer and longer, reaching nearly> 20 seconds in some > situations. I realize that this is most likely a> snowball effect, where once > it hits a snag, the queries just pile up and> become slower as a result. Does > anyone have any configuration tips or> thoughts on how to help speed this up > and prevent the slowdown?>> Here is our my.cnf configuration:>> # The MySQL > server> [mysqld]> port = 3306> socket > = /var/lib/mysql/mysql.sock> max_connections = > 200> skip-locking> key_buffer = 16M> max_allowed_packet > = 8M> table_cache = 1024> sort_buffer_size > = 2M> read_buffer_size = 2M> read_rnd_buffer_size > = 8M> myisam_sort_buffer_size = 8M> thread_cache_size > = 16> query_cache_size = 128M> query_cache_limit > = 2M> long_query_time = 1> tmpdir = /tmp> datadir = > /var/lib/mysql> thread_concurrency = 16>> # InnoDB settings> > innodb_file_per_table> innodb_data_home_dir = /var/lib/mysql/> > innodb_data_file_path = ibdata1:10M:autoextend> > innodb_log_group_home_dir = /var/lib/mysql/> innodb_log_arch_dir > = /var/lib/mysql/> innodb_log_files_in_group = 2> > innodb_buffer_pool_size = 24576M> innodb_additional_mem_pool_size = > 20M> innodb_log_file_size = 512M> innodb_log_buffer_size > = 16M> innodb_flush_log_at_trx_commit = 1> innodb_lock_wait_timeout = > 50> innodb_thread_concurrency = 8>> [mysqldump]> quick> > max_allowed_packet = 16M> [mysql]> no-auto-rehash> # Remove the next comment > character if you are not familiar with SQL> #safe-updates> [isamchk]> > key_buffer = 256M> sort_buffer_size = 256M> read_buffer > = 2M> write_buffer = 2M> [myisamchk]> key_buffer > = 256M> sort_buffer_size = 256M> read_buffer = 2M> > write_buffer = 2M> [mysqlhotcopy]> interactive-timeout> If there > is any other information that would be helpful, please let me> know.>> Thanks > for any help!>> -David>>> > ------------------------------------------------------------------------>> > _______________________________________________> DBmail mailing list> > [email protected]> https://mailman.fastxs.nl/mailman/listinfo/dbmail-- > ________________________________________________________________ Paul Stevens > paul at nfg.nl NET FACILITIES GROUP > GPG/PGP: 1024D/11F8CD31 The > Netherlands________________________________http://www.nfg.nl_______________________________________________DBmail > mailing [EMAIL PROTECTED]://mailman.fastxs.nl/mailman/listinfo/dbmail Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it! _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail -- Vapour Forge Jake Anderson Project Manager Mobile: 0412 897 125 Email: [EMAIL PROTECTED] Web Page: www.vapourforge.com Your source for custom IT services _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us
<<attachment: vf.gif>>
_______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
