2009-03-05 15 views
12

Cuando sabe que su software (no un controlador, que no forma parte del sistema operativo, solo una aplicación) se ejecutará principalmente en un entorno virtualizado ¿existen estrategias para optimizar su código y/o la configuración del compilador? ¿O alguna guía sobre lo que debes y no debes hacer?Optimización de software para máquinas virtuales

Esto no se trata de una ganancia de rendimiento del 0,0x%, pero tal vez, simplemente hay cosas simples que mejorarán el rendimiento drásticamente o cosas que parecen simples pero que se sabe que son desastrosas en entornos virtualizados. Por ejemplo, habilitar CONFIG_PARAVIRT en una compilación de kernel se realiza fácilmente y puede aumentar mucho el rendimiento. Ahora estoy buscando cosas similares para las aplicaciones, si las hay.

En mi caso será C++ Code y probablemente VMWare, pero quiero mantener la pregunta como idioma/producto-agnóstico como sea posible. Me pregunto si incluso existen tales estrategias o si esto sería una completa pérdida de tiempo; después de todo, el concepto de virtualización es que no tiene que preocuparse demasiado por ello.

Respuesta

3

El único consejo que puedo darte es el uso cuidadoso de mlock()/mlockall() .. mientras busco controladores de globo con errores.

Por ejemplo, si un invitado Xen se inicia con 1 GB, luego se redujo a 512 MB, es muy típico que el dominio privilegiado NO analice la cantidad de memoria que promete el kernel paravirtualizado para procesar (es decir, Committed_AS). En realidad, con Xen, a menos que este valor se coloque en Xenbus, el host privilegiado no tiene idea de lo que hará un globo. Creo que esto también coincide con KVM, dependiendo de cómo esté configurado el kernel ... pero su pregunta presupone que no sabemos nada acerca de tales cosas :)

Proteja las cosas (tenga cuidado pero sea prudente) que simplemente no pueden ser paginado, siempre cuenta para el escenario 'cielo está cayendo'.

Del mismo modo, el uso de posix_fadvise()/posix_madvise() para decirle al kernel de PV cuánto necesita o no necesita almacenar en búfer siempre es una buena idea.

Más allá de eso, hay muy poco que puedes hacer ... ya que estás hablando solo del kernel paravirtualizado, que está diseñado para hacer que los procesos olviden la virtualización en primer lugar.

No uso mucho KVM (todavía), aunque planeo explorarlo más en el futuro. Sin embargo, el 90% de las cosas que he estado escribiendo últimamente está específicamente diseñado para ejecutar en invitados Xen paravirtualizados. Siento ser un poco más centrada en Xen/C, pero ahí es donde mi experiencia y es pv_ops está en la línea principal (pronto también xen-ops) 0 :)

Buena pregunta, por cierto :)

Editar:

Cuando dije 'cuidado pero prudente', quise decir un paso por encima de conservador. Si su programa asigna alguna estructura de trabajo que la mayoría de las funciones necesitan, trábela. Si sus búferes de asignación leen archivos enormes, no los bloquee ... y asegúrese de llamar a posix_fadvise() para informarle al kernel que solo tiene la intención de acceder a él una vez (si ese es el caso). Además, asegúrese de informar al kernel sobre el uso de los archivos mapeados en la memoria, especialmente si sirven para organizar la concurrencia.

En resumen, ayude a sus anfitriones gestionar la memoria del kernel, no deje que los bloques asignados críticos son arrojados en paginación sucio, no asuma que su programa es más importante que cualquier otra cosa mediante el bloqueo de todo lo que asigna :)

Perdón por la ambigüedad. La mejor frase que pude encontrar fue 'cuidadosa, pero prudente'.

+0

+1, pero, "(tenga cuidado, pero prudente)"? ¿Qué quieres decir? esos son prácticamente sinónimos ... –

+0

Editado para explicar :) –

+0

+ 1.adición: "Al escribir esto (2.6.21) Linux no recuerda POSIX_FADV_DONTNEED asesoramiento para un archivo abierto. Actúa cuando se da el consejo, y cuando no puede cumplirlo olvida el consejo. Por lo tanto, depende de usted asegurarse de que Linux cumpla ". – VolkerK

1

Mi único consejo es mantener su memoria y el uso de IO bajo si es posible.

IO en una VM es bastante lento en comparación con el hardware físico. Si puedes evitar hacerlo, entonces evítalo.

1

Las cosas que son lentas en el hardware real son incluso más lentas cuando el sistema está virtualizado. Depende de la tecnología de virtualización que se use, cuanto más lentos se vuelvan.

Especialmente evite todo lo que requiera E/S con el mundo fuera del entorno virtual. Depende de cómo se configuran las cosas, esto incluye dibujar en la pantalla, intercambiar y E/S de disco y red. Eso es más o menos en un orden decreciente de importancia.

Si es posible, imagina que estás escribiendo para una computadora de diez años. Si su aplicación funcionaría en una computadora de escritorio 1999, o una computadora portátil, debería hacerlo bien.

4

He encontrado que todo se trata de E/S.

Las máquinas virtuales normalmente chupan increíblemente mal en IO. Esto hace que varias cosas sean mucho peores de lo que serían en el estaño real.

El intercambio es especialmente un mal asesino, destruye completamente el rendimiento de VM, incluso un poco, ya que IO es muy lento.

La mayoría de las implementaciones tienen una gran cantidad de contención de E/S entre máquinas virtuales, no he visto ninguna que evite esto o lo maneje con sensatez.

Así que utilice una ramdisc para archivos temporales si puede, pero no la cambie, porque eso sería aún peor.

+0

IO cuando un programa está codificado de una manera para cooperar con el kernel y 2 ejecutándose en un kernel con los controladores PV apropiados no es un problema. Esta pregunta realmente saca a la luz lo bien que se entiende el kernel de host, la virtualización o no. Por favor, discuta los detalles de E/S, más allá de 'do not do it'. –

Cuestiones relacionadas