How to optimize table_cache?

The reason you didn't find an answer is that there's not an answer. The appropriate value for table_cache doesn't correlate to an amount of system memory.

Note that table_cache was renamed table_open_cache in MySQL 5.1.3 and is referred to by the new name in newer versions of MySQL.

As I mentioned in my answer to this similar recent question, among the things that can increment opened_tables, some of them are both harmless and inevitable (such as making backups with mysqldump, which, in most cases, issues some variant of FLUSH TABLES, which increments the counters as each table is reopened after the flush, either for the purpose of backing up the table or by other client threads accessing the recently-flushed tables, which must naturally be re-opened).

What I didn't think to mention in that post is -- and I trust you will find some measure of amusement in this -- that the act of running mysqltuner against your server can, itself, increment the opened_tables counter, thus invalidating its own results.

A commenter on my answer referenced this article, where the author points out that tweaking table_cache worsens performance the more "optimally" you set it.

The bottom line is that this is a good example of a variable that is best left alone unless you have a specific reason to tweak it, and the output of a tuning script doesn't count. Tuning scripts are often well-intentioned but that is sometimes the best thing that can be said about them:

The problem with correlations that sometimes appear to be true is that people begin to believe they will always be true. Oracle DBAs abandoned ratio-based tuning years ago, and we wish MySQL DBAs would follow their lead.

We wish even more fervently that people wouldn’t write “tuning scripts” that codify these dangerous practices and teach them to thousands of people. This leads to our second suggestion of what not to do: don’t use tuning scripts! There are several very popular ones that you can find on the Internet. It’s probably best to ignore them.

We also suggest that you avoid the word “tuning,” which we’ve used liberally in the past few paragraphs. We favor “configuration” or “optimization” instead (as long as that’s what you’re actually doing; see Chapter 3). The word “tuning” conjures up images of an undisciplined novice who tweaks the server and sees what happens. We suggested in the previous section that this practice is best left to those who are researching server internals.

“Tuning” your server can be a stunning waste of time.

^{-- Schwartz, Baron; Zaitsev, Peter; Tkachenko, Vadim (2012-03-05). High Performance MySQL: Optimization, Backups, and Replication (Kindle Locations 12173-12182). OReilly Media - A. Kindle Edition.}

As a side note, MySQL 5.0 is end of life. MySQL 5.0.67 was released over 4 years ago and a significant number of bugs were fixed in the 5.0 release series since then. If I had a 5.0.67 server, and it was working, then the last thing I would want to do would be to change anything about its configuration.

You are opening less than 1 table per hour. That is insignificant.

The metric that should have been looked at is Opened_tables / Uptime. That's "per second".

I suggest that anything under 2/sec is fine.

Back to the title question:

Consider increasing table_open_cache if

Opened_tables / Uptime > 2
Opened_table_definitions / Uptime > 1
Table_open_cache_misses / Uptime > 1
Table_open_cache_overflows / Uptime > 1
Open_tables = table_open_cache

If you can't raise it, check open_files_limit and the OS limit.

If your MySQL is new enough, set table_open_cache_instances to (perhaps) the number of cores you have.