Bueno bueno, vamos mejorando
Para hacer los cálculos, el número de visitas en sí no es muy relevante. Tu servidor puede soportar hasta cierta carga, y evidentemente ese límite no depende del número de visitas que tengas sino del hardware en sí. Si después de configurarlo todo correctamente resultara que no tiene suficiente potencia para aguantar tu numero de visitas, tu unica opción será pasarte a un trasto más grande. Aún así, lo que debería pasar si llegas a ese umbral es que rechazara conexiones por sobrecarga, en vez de morirse agónica y silenciosamente como te pasaba antes.
En cuanto a los cálculos, parece que de base tu sistema usa unos 450mb de ram (es decir, con apache aguantando el mínimo número de threads que tienes configurado, y con todos los demás servicios chupando ram). Además, tienes 1Gb de ram en total que hoy en día es muy justito, nada cercano a "large site"...
Dicho esto, lo que deberías hacer primero es calcular cuanto te gasta cada nuevo proceso php. En mi opinión la mejor forma de hacerlo es mirar la memoria (free -m, los valores de la línea +/- buffer cache) justo después de hacer un "killall /usr/bin/php5-cgi" (es decir, sin procesos php corriendo) y volverla a mirar después de hacer una sola visita a una sola web (lo que obligará a lanzar un solo proceso php5-cgi).
Hecho esto, puedes tomar la diferencia que te salga como el consumo de un proceso php. Pongamos que te da 30Mb. En ese caso, podrías tener hasta 500(mb libres)/30(mb por proceso)= 17 procesos php como mucho sin saturar la máquina. Ahí ya tienes el valor para "MaxProcessCount" en /etc/apache2/mods-enabled/fcgid_ispcp.conf. Con eso ya deberías evitar que se sature el servidor.
Ahora te queda decidir cuantos de esos 17 procesos le permites usar a una sola de las webs. Es decir, si resulta que una web tiene un pico de visitas bestias, le permites llegar a utilizar todos los procesos dejando las demás webs sin poder funcionar? Imagino que no, así que pon de "DefaultMaxProcessClass" algo como 10 o 15 (cuanto más bajo menor el pico que puede aguantar una sola web, pero más seguro que las demás siguen funcionando).
Luego te queda configurar apache. Ten en cuenta que apache sirve directamente las peticiones que no són de archivos PHP, así que lo que necesitas en este paso es saber más o menos la proporción de peticiones PHP frente a peticiones no-PHP (imagenes, archivos css, javascripts, etc..). Supongamos que de cada 10 peticiones, 2 son de archivos PHP y 8 de otras cosas (ratio:8/2=4). Sabemos que no puedes procesar nunca más de 17 peticiones PHP a la vez (lo que hemos calculado arriba), así que apache debería aceptar 17 (peticiones php) + 17*4 (no php) = 85 conexiones simultáneas. Redondeamos a la alza (aunque no mucho) y diremos que 100 conexiones simultáneas estaría bien.
Así pues, ya tenemos que "MaxClients" (en /etc/apache2/apache2.conf, sección <IfModule mpm_worker_module>) debería ser 100. Ponemos "ThreadsPerChild" a 25 (que es el valor por defecto, compromiso entre que todo vaya bien y que no chupe demasiado), y sabemos que nunca tendremos más de 100/25=4 procesos apache "workers" a la vez más el master = 5 procesos apache en total.
Ahora reiniciamos apache y dejamos que el servidor opere con normalidad. Luego haces un poco de seguimiento del consumo de memoria y deberías ver que ya no se muere como antes. Si ocurre, a mirar qué parte está gastando más de lo que preveíamos y a reajustar...