This is not an error from the application - rather it is an error from the shell tell you the ARG_MAX limit has been reached. Here is what you can do to avoid/get around that:

If you find that you can not compress a directory because it contains to many files, you can do one of two things:

Compress the container directory or:

Generate the file list
find -iname '*.ext' > file_list.txt

Run tar, passing it the file list
tar czvf archive.tar.gz --files-from file_list.txt

Shorthand of this would be:
find . -name '*.ext' -print | tar -cvzf archive.tar.gz --files-from -

The INFORMATION_SCHEMA database contains a wealth of information regarding your database(s), but is only available for MySQL 5.0 and up. One way I like to query the INFORMATION_SCHEMA database will return the Database | Table | Size for each table you've got. Here's what the SQL looks like:

SELECT TABLE_SCHEMA AS 'Database', TABLE_NAME AS 'Table',
CONCAT(ROUND(((DATA_LENGTH + INDEX_LENGTH - DATA_FREE) / 1024 / 1024),2)," MB") AS Size FROM INFORMATION_SCHEMA.TABLES;

Once you execute this SQL, you will get a nice list of your tables, along with their size, in MB. Feel free to adjust as necessary to retrieve additional data, or in different formats. If you have a format you really like, share it!

What MySQL users need to understand is that queries generally execute very fast. A busy server should really never need more than 200 concurrent connections for any given user. The trick in solving this problem is to understand why it is happening. What is stopping your queries from executing fast?

Many times, the problem is as simple as your daily backups running. If your database is large and the backup takes 10 or 15 minutes to process, then all of the queries coming into the database will queue up and wait for the backup to finish. Processing 20 - 50 queries per second, it's not hard to do the math - your server could easily hit 200 connections queued waiting for the backup to finish - within seconds.

Solutions to this case can range from the simple, for instance, scheduling your backups to run at a time where you do not expect any traffic - to the more complex such as using replication as a backup aid. (Replication is something I will get into in later postings.)

Lastly, a backup of connections can always be caused from table locking issues, or slow queries (they take a long time). Running 1 complex query which takes 300 - 500 seconds to complete may indeed lock your table, preventing other queries from accessing the same data. You can always get a hint at what kind of queries are taking a long time to execute by logging the slowest of them. This "slow-query-log" can be enabled in your MySQL configuration file, commonly located at /etc/my.cnf by adding the following under the "[mysqld]" section:

log-slow-queries=/the/log/file/path

Where /the/log/file/path is wherever you want the file kept. You must restart MySQL after adding this setting.

When analyzing this file, it's always helpful to use "mysqldumpslow". I'm not going to give you all the answers, but if you want to learn how to use it to help analyze your slow query log, try:

mysqldumpslow --help

The command is formatted as follows:

ln -s existing_file new_file

You can use this to link directories as well.

ln -s /usr/src /usr/local/src

ServerSignature Off
ServerTokens Prod

Add this to your httpd.conf

TraceEnable off

Alternatively, if not using 1.3.34 or 2.0.55+, you can add this to your httpd.conf:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]

Add the following to httpd.conf:

SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT56:+HIGH:+MEDIUM:-SSLv2:-RC4:+EXP

It's as easy as:

pecl install apc

You'll just have to add the extension in your PHP.ini and restart Apache.

Check out the APC Homepage