If you enable APC in the main php.ini of a mod_php environment you'll have pretty much any PHP script on the server hitting the same shared APC memory. This will very likely exhausting the APC cache and cause the cache to frequently fill and fragment. Also, it's harder to debug APC if there are lots of different sites sharing the memory.
As an aside, you should copy the apc.php file from the installation directory to a virtualhost and then visit that script. It will give you losts of stats about who is calling APC. Don't forget to edit the file and set a password.
This example works for mod_php environments. If you're running mod_suphp or mod_fcgid then there are similar override solutions. This comes in handy for older cPanel/WHM shared hosting environments that are stuck on mod_php.
Set apc.cache_by_default=0 in the main php.ini for the hosting server. Restart or reload Apache.
Within a Drupal settings.php file you can simply enable APC as desired, like
Alternatively, you could enable APC at a broader level through an Apache .conf file (virtualhost-level) or a .htaccess (directory-level). This effectively gives you per-user or per-domain APC.
php_flag apc.cache_by_default on
As described in this Xerosphere article on APC and Drupal, you can use apc.filters to only apply APC on file or directory patterns. For instance, the code below would only run on directories named somedir.
You should not run APC with mod_fcgid, at least according to Rasmus, who says to use PHP-FPM. Also, according to the Apache documentation for mod_fcgid, The popular APC opcode cache for PHP cannot share a cache between PHP FastCGI processes unless PHP manages the child processes. Thus, the effectiveness of the cache is limited with mod_fcgid; concurrent PHP requests will use different opcode caches.
In an environment like Drupal, mod_fcgid, and APC you're likely to get weird results. For example, say there are 5 php-cgi processes running under Apache threads. Every time a page is loaded you don't know which opcode cache is being used. So, you will have more "misses" and use as much as 5 times more memory on a busy site. Worse yet, when you click Drupal's "Clear Cache" button it's going to clear just 1 of the 5 opcode caches. That scenario can easily lead to 500 errors when you update Drupal modules and need to clear the cache.