<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Terminus a Quo &#187; CentOS/RHEL</title>
	<atom:link href="http://abing.gotdns.com/posts/category/system-administration/centosrhel/feed/" rel="self" type="application/rss+xml" />
	<link>http://abing.gotdns.com</link>
	<description>Because you can never have too many blogs on the Internet...</description>
	<lastBuildDate>Tue, 19 May 2009 00:23:13 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>MySQL Performance Tuning on Centos 5.1</title>
		<link>http://abing.gotdns.com/posts/2008/mysql-performance-tuning-on-centos-51/</link>
		<comments>http://abing.gotdns.com/posts/2008/mysql-performance-tuning-on-centos-51/#comments</comments>
		<pubDate>Sat, 17 May 2008 14:12:35 +0000</pubDate>
		<dc:creator>nimrod.abing</dc:creator>
				<category><![CDATA[CentOS/RHEL]]></category>
		<category><![CDATA[MySQL]]></category>
		<category><![CDATA[System Administration]]></category>

		<guid isPermaLink="false">http://abing.gotdns.com/?p=147</guid>
		<description><![CDATA[Last week I installed SugarCRM for arsenic.ph to try it out. While I was playing around with adding new users and roles, I noticed that it took over a minute for SugarCRM to finish creating one user. I began investigating and slow queries notwithstanding, MySQL turned out to be the performance bottleneck. This server is [...]
<p>a</p>
]]></description>
			<content:encoded><![CDATA[<p>Last week I installed SugarCRM for arsenic.ph to try it out. While I was playing around with adding new users and roles, I noticed that it took over a minute for SugarCRM to finish creating one user. I began investigating and slow queries notwithstanding, MySQL turned out to be the performance bottleneck. This server is still new and I still have not come around to tuning MySQL as I have already begun moving most of my work to Postgres. Unfortunately there are still a large number of good software packages out there that require MySQL so I was left with no choice but to tune it.</p>

<p><span id="more-147"></span></p>

<p>Running <code>sql-bench/run-all-tests</code> from the mysql-benchmark suite I got the following:</p>

<pre><code>
alter-table: 
Total time: 14 wallclock secs ( 0.01 usr  0.01 sys +  0.00 cusr  0.00 csys =  0.02 CPU)
ATIS: Total time:  3 wallclock secs ( 2.58 usr  0.10 sys +  0.00 cusr  0.00 csys =  2.68 CPU)
big-tables: Total time:  5 wallclock secs ( 2.33 usr  0.17 sys +  0.00 cusr  0.00 csys =  2.50 CPU)
connect: Total time: 49 wallclock secs (12.93 usr  7.55 sys +  0.00 cusr  0.00 csys = 20.48 CPU)
create: Total time: 59 wallclock secs ( 1.06 usr  0.50 sys +  0.00 cusr  0.00 csys =  1.56 CPU)
<strong>insert: Total time: 853 wallclock secs (151.16 usr 20.44 sys +  0.00 cusr  0.00 csys = 171.60 CPU)</strong>
select: Total time: 42 wallclock secs (13.51 usr  1.32 sys +  0.00 cusr  0.00 csys = 14.83 CPU)
transactions: Test skipped because the database doesn't support transactions
wisconsin: Total time:  3 wallclock secs ( 1.18 usr  0.27 sys +  0.00 cusr  0.00 csys =  1.45 CPU)
</code></pre>

<p>As I had suspected, insert performance was way too slow. In this case it took over 14 minutes to run the entire test-insert suite which runs about 500,000+ queries. Normally this would not be an issue but SugarCRM has a lot of <code>insert</code>s to do when it creates a new user or a new role. Clearly something needs to be done about slow inserts. Turn out MyISAM is not really good when it comes to <code>insert</code>s so MySQL needs a little help on the configuration side to improve things.</p>

<p>After about half an hour of playing around with <code>/etc/my.cnf</code> I finally managed to cut down execution time for <code>insert</code>s while keeping the other operations at almost the same level of performance. The results:</p>

<pre>
alter-table: Total time: 14 wallclock secs ( 0.01 usr  0.01 sys +  0.00 cusr  0.00 csys =  0.02 CPU)
ATIS: Total time:  3 wallclock secs ( 2.58 usr  0.08 sys +  0.00 cusr  0.00 csys =  2.66 CPU)
big-tables: Total time:  5 wallclock secs ( 2.32 usr  0.21 sys +  0.00 cusr  0.00 csys =  2.53 CPU)
connect: Total time: 46 wallclock secs (13.42 usr  6.37 sys +  0.00 cusr  0.00 csys = 19.79 CPU)
create: Total time: 60 wallclock secs ( 1.07 usr  0.59 sys +  0.00 cusr  0.00 csys =  1.66 CPU)
<strong>insert: Total time: 439 wallclock secs (141.66 usr 21.48 sys +  0.00 cusr  0.00 csys = 163.14 CPU)</strong>
select: Total time: 43 wallclock secs (13.57 usr  1.40 sys +  0.00 cusr  0.00 csys = 14.97 CPU)
transactions: Test skipped because the database doesn't support transactions
wisconsin: Total time:  3 wallclock secs ( 1.21 usr  0.24 sys +  0.00 cusr  0.00 csys =  1.45 CPU)
</pre>

<p>That&#8217;s a 64% improvement in the insert benchmark, the rest of the benchmarks are largely unchanged. The whole shebang of settings are as follows:</p>

<pre><code>
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
skip-name-resolve
back_log = 75
max_connections = 500
key_buffer = 384M
myisam_sort_buffer_size = 64M
join_buffer_size = 1M
read_buffer_size = 1M
sort_buffer_size = 2M
table_cache = 1800
thread_cache_size = 384
wait_timeout = 7200
connect_timeout = 10
tmp_table_size = 64M
max_heap_table_size = 64M
max_allowed_packet = 64M
max_connect_errors = 1000
read_rnd_buffer_size = 524288
bulk_insert_buffer_size = 16M
<strong>query_cache_min_res = 2K</strong>
query_cache_limit = 4M
<strong>query_cache_size = 32M</strong>
<strong>query_cache_type = 1</strong>
query_prealloc_size = 65536
query_alloc_block_size = 131072
</code></pre>

<p>Most of these settings came from here: <a href="http://www.debianhelp.co.uk/mysqlperformance.htm">http://www.debianhelp.co.uk/mysqlperformance.htm</a>. I played with some of the settings based on sql-bench results in addition to using <a href="http://hackmysql.com/mysqlreport">mysqlreport</a> to further fine-tune the settings. You might need to adjust your own settings to match your needs though. As for me, I&#8217;m happy with the results although I know things can be further tuned for performance using OS-level tweaks. But as far as I can tell, OS-level tweaks will only cause marginal performance improvements anyway.</p>

<p>Oh, and as for SugarCRM I removed it and used <a href="http://www.vtiger.com/">vTiger</a> instead,</p>

<p>a</p>
]]></content:encoded>
			<wfw:commentRss>http://abing.gotdns.com/posts/2008/mysql-performance-tuning-on-centos-51/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Getting Postfix to run SMTPS on port 465</title>
		<link>http://abing.gotdns.com/posts/2008/getting-postfix-to-run-smtps-on-port-465/</link>
		<comments>http://abing.gotdns.com/posts/2008/getting-postfix-to-run-smtps-on-port-465/#comments</comments>
		<pubDate>Sun, 27 Apr 2008 05:41:21 +0000</pubDate>
		<dc:creator>nimrod.abing</dc:creator>
				<category><![CDATA[CentOS/RHEL]]></category>
		<category><![CDATA[System Administration]]></category>

		<guid isPermaLink="false">http://abing.gotdns.com/?p=143</guid>
		<description><![CDATA[While setting up my new server, I followed the guide found here. Because of SmartBro&#8217;s braindead policy of forcing its subscribers to use their flaky SMTP server, I am forced to work around this issue by running SMTPS instead. I followed Step 5 of the guide and I was wondering why Evolution could not connect [...]
<p>a</p>
]]></description>
			<content:encoded><![CDATA[<p>While setting up my new server, I followed the guide found <a href="http://howtoforge.com/centos-5.1-server-lamp-email-dns-ftp-ispconfig" title="CentOS 5.1 Server Setup: LAMP, Email, DNS, FTP, ISPConfig (a.k.a. The Perfect Server)">here</a>. Because of SmartBro&#8217;s braindead policy of forcing its subscribers to use their flaky SMTP server, I am forced to work around this issue by running SMTPS instead. I followed <a href="http://howtoforge.com/centos-5.1-server-lamp-email-dns-ftp-ispconfig-p5" title="CentOS 5.1 Server Setup: LAMP, Email, DNS, FTP, ISPConfig (a.k.a. The Perfect Server) - Page 5">Step 5</a> of the guide and I was wondering why Evolution could not connect to the server. I have already enabled port 465 to go through on Bastille firewall but running <code>nmap</code> on the server does indicate that Postfix was not listening on port 465 as it should be.</p>

<p>I even went as far as regenerating my self-signed SSL certificates to be sure I had everything buttoned down. This just another one of those face-in-palm moments where the cause of the problem was so obvious. I forgot to enable SMTPS in <code>master.cf</code>. I simply uncommented the following lines in <code>master.cf</code>:</p>

<pre><code>smtps     inet  n       &amp;#8211;       n       &amp;#8211;       &amp;#8211;       smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
</code></pre>

<p>Then I restarted Postfix and <code>nmap</code> now reports port 465 open.</p>

<p>a</p>
]]></content:encoded>
			<wfw:commentRss>http://abing.gotdns.com/posts/2008/getting-postfix-to-run-smtps-on-port-465/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
	</channel>
</rss>
