jerclarke's questions

We're setting up a redirection-based mail server with a lot of complex moving parts, including the standard ones that apply to everyone like SPF/TLS as well as the more complex ones needed to ensure redirect mail gets accepted like SMTP authentication for Gmail, SRS, DKIM and the SPF complications that arise.

I've been sending messages to gmail and inspecting the headers myself, but it's tedious and easy to miss problems. What I'd like is a service where I can send an email from our server (or from a SMTP-authenticated Gmail account) and get a report about the various technologies and whether they are working or not.

Note that I'm not looking for a tool to assess a mail server from outside, as http://mxtoolbox.com/ already does a great job of that as well as many other things. Another similar tool with slightly different coverage is http://www.intodns.com/ Both of these are really useful but only for testing your server from the outside. I want a service that recieves email and assess the aspects that can only be tested at that point in the process.

On our server we have a LOT of RAM for our traffic levels (16GB). The HTTP processes regularly eat up all CPU and need to be restarted without even getting close to using swap memory, so I'm looking for ways to spend RAM to ease the load on Apache (and/or help the seperate MySQL server which may be breaking Apache).

I have many WordPress installs on the HTTPD instance so APC sometimes uses as much as 900MB of ram (according to the apc.php charts). Just in case I have apc.shm_size set to 1600MB which is more than it needs but not more than I can spare. This means there is usually lots of extra RAM available to APC but also very little turnover and fragmentation is never more than 1%.

Is this dangerous? Should I be slimming down APC to less than 1GB just on principle? Should I be expecting some turnover within APC in the name of bringing it's overall footprint down?

Having so much memory devoted to APC means that in top/htop every single httpd process shows ~1.9GB in the VIRT memory column. Obviously this is shared memory and not used per-process, but could it be hurting our server?

NOTE: The problem with the server remains unclear but the effect is that about 60 times a day all 8 CPU's fill up to 100% and everything stops working until Monit sees that Apache is broken and restarts it (Monin also saves the MySQL server). I'm not sure if APC is even part of the problem but I'm trying to optimize everything just in case.

I'm having a lot of issues with a dedicated MySQL server and it seems like upgrading to the XtraDB version of InnoDB will probably have a positive effect, but I'm hesitant to get involved with it since I am not really a sysadmin and prefer to stick with things that start with "yum update".

What is the easiest way to get XtraDB installed? Should I use the Percona server? MariaDB? OurDelta? Is there a way to avoid using custom RPMs and sticking to a repo instead?

The current yum version of MySQL is 5.0.xx, whereas a lot of the alternate MySQL builds are based on 5.1.xx. How does this factor in? Do I need to figure out 5.1 on CentOS before working on getting XtraDB in?

For bonus points: Do I need to seriously test XtraDB with my server before implementing it, or is it relatively safe to have the brief downtime for switching servers followed by putting the site back online with XtraDB?

I have been using the tuning-primer.sh script to tune my my.cnf settings. I have most things working well but the part about TABLE CACHE makes no sense:

TABLE CACHE Current table_cache value = 900 tables.

You have a total of 0 tables You have 900 open tables.

Current table_cache hit rate is 1% , while 100% of your table cache is in use.

You should probably increase your table_cache

When I do SHOW STATUS; I get the following table-related numbers:

Open_tables = 900

Opened_tables = 0

It seems like something is going wrong. I have some extra memory I could use on increasing the table_cache size, but my sense is that the 900 tables already available aren't doing anything, and increasing it will just waste more energy.

Why might this be happening? Are there other settings that could cause all my table_cache slots to be used even though there are no hits to them?

I have 150 max connections and probably no more than 4 tables per join, FWIW.

Here is the tuner script output for temp tables, which I've also been tuning:

TEMP TABLES

Current max_heap_table_size = 90 M

Current tmp_table_size = 90 M

Of 11032358 temp tables, 40% were created on disk

Perhaps you should increase your tmp_table_size and/or max_heap_table_size to reduce the number of disk-based temporary tables.

Note! BLOB and TEXT columns are not allow in memory tables.

If you are using these columns raising these values might not impact your ratio of on disk temp tables.