12 votos

Es malo tener una muy completa de la unidad de disco duro en un alto tráfico de servidor de base de datos?

La ejecución de un Ubuntu server con MySQL para un alto tráfico de la producción de la base de datos del servidor. Nada más se está ejecutando en la máquina, excepto la instancia de MySQL.

Almacenamos diaria de la base de datos de copias de seguridad en el servidor de DB, ¿hay algún impacto en el rendimiento o la razón por la cual debemos mantener el disco duro relativamente vacío? Si el disco está lleno hasta el 86%+ con la base de datos y todas las copias de seguridad, ¿te duele el rendimiento?

Así que sería la base de datos del servidor que ejecuta con 86-90%+ capacidad de realizar menos bien en cualquier manera que el servidor que ejecuta con sólo un 10% de disco completo?

El tamaño total del disco en el servidor es de más de 1 TB para que ni el 10% de la disco debería ser suficiente para que el básico de S/S de intercambio y tal.

11voto

HeatfanJohn Puntos 328

Primero de todos usted NO desea mantener su base de datos de copias de seguridad en la misma unidad física o grupo de RAID como su base de datos. La razón de esto es que una falla en el disco (si se ejecuta sin ningún tipo de protección RAID) o un catastrófico fallo de RAID (si utiliza RAID 1 o RAID-5) va a causar que usted pierda su base de datos y la base de datos de copias de seguridad.

Su pregunta acerca del rendimiento de disco se refiere a cómo se completa una unidad de disco depende de cómo los datos en el disco se accede. Para girar los discos hay dos factores físicos que afectan el rendimiento de e/S. Ellos son:

  • tiempo de búsqueda - que es el tiempo que tarda la unidad de disco para mover el disco la cabeza de su actual posición en la pista de la pista que contiene la los datos solicitados

  • de rotación de la latencia, que es el promedio de tiempo que toma para que el datos que desee para llegar a la cabeza de lectura como la unidad gira - para un 15K RPM esta unidad es de 2 ms (milisegundos)

Cómo completo de la unidad que puede afectar el tiempo medio de búsqueda de su servidor de e/s están experimentando. Por ejemplo, si la unidad está llena y tiene tablas de base de datos que se encuentran físicamente en la unidad en el extremo de los extremos opuestos de la disco, los discos, entonces como realizar e/s de acceso a los datos de cada una de estas tablas de los I/Os va a experimentar el máximo tiempo de búsqueda de la unidad.

Dicho esto, sin embargo, si la unidad es completa y su aplicación tiene acceso a sólo una pequeña fracción de los datos almacenados en la unidad y todos los de este se encuentran los datos de forma contigua en la unidad, a continuación, estos I/Os se vean afectadas por el tiempo de búsqueda.

Por desgracia, la respuesta a esta pregunta es que "su kilometraje puede variar", lo que significa que la manera en que la aplicación tiene acceso a los datos y donde se encuentran los datos de determinar lo que su rendimiento de e/S será.

También, como se ha mencionado por @gravyface, sería la "mejor práctica" para separar el sistema operativo de los requisitos de almacenamiento de la base de datos. De nuevo, esto sería para ayudar a minimizar el movimiento de la cabeza en la superficie del disco como de tener los dos en la misma unidad podría causar búsqueda constante entre el sistema operativo y base de datos de las áreas de la unidad como el sistema operativo y el software de base de datos realizar solicitudes de I/O.

8voto

voretaq7 Puntos 63415

Hay dos ángulos a considerar aquí: Rendimiento y Robustez.

En cuanto al rendimiento, se recomienda tener separados los ejes de disco (RAID o grupos / conjuntos de unidades) para:

  1. El sistema operativo cosas (binarios, registros, directorios, etc.)
  2. El espacio de intercambio (que puede ser combinado con (1) si usted no espera que el uso de swap)
  3. La base de datos de Producción
  4. La base de datos de Producción de los registros de transacciones (si se utiliza)
  5. Volcados de base de datos/copia de seguridad

El razonamiento detrás de esto es muy sencillo: Usted no quiere que la DB de desempeño impactado por "otras cosas" que exigen el disco (por ejemplo, si la máquina comienza el intercambio fuertemente y la partición de swap es en el otro lado del disco desde la base de datos de disco largas busca contender con).


Desde un punto de vista de la robustez desea que el mismo tipo de avería, pero por una razón diferente: Como otros han señalado que no quiere un disco que ha fallado a sacar tanto tu DB y de sus copias de seguridad (aunque de manera realista que usted debe copiar las copias de seguridad desde el servidor de todos modos en el caso de una falla catastrófica).

Usted también querrá evitar cualquier configuración con un monolítico / de la partición que contiene todo ... este es un lamentable y trágico, y alarmantemente común error cometido en el mundo de Linux que no es compartida por los otros sistemas similares a Unix.
Como Gravyface menciona en su comentario, si de alguna manera se las arreglan para rellenar / su sistema casi seguro de accidente y de limpieza/recuperación puede ser largo y costoso si el sistema tiene una única / partición en lugar de una bien estructurada jerarquía de puntos de montaje.

5voto

Asok Puntos 121

Me gustaría recomendar mover la base de datos y temporal (ver más abajo) de las copias de seguridad en una partición diferente de la root (/).

Además, vienen con un razonable rotación de retención/esquema para su (se supone) comprimido volcado de base de datos de copias de seguridad. Hay (por lo general) no hay razón para que muchas de las copias de las copias de seguridad en el disco local. No hace nada para la recuperación de desastres y cuando se mueve fuera del sitio, debe ser eliminado del disco.

Eso es casi un procedimiento operativo estándar.

4voto

M Afifi Puntos 657

Esto me recordó a un error en NetApp, donde los sistemas de archivos que están cerca de la plena tenido su rendimiento disminuye significativamente (como la mitad). (hay que admitir que fue hace un par de años.

La respuesta, como todo el mundo dice es que depende, pero vale la pena pensarlo.

El principal inconveniente de archivo completo de los sistemas es la lista de inodos libres son propensos a ser fragmentados y en todo el lugar.

Hay tres tipos de datos que se encuentran en el disco duro para una base de datos.

  1. Su archivo de base de datos. Este será un gran preasignados archivo que crece generalmente en trozos grandes (de 10% por ejemplo).
  2. Los registros, el registro de transacciones que se está escrita continuamente, se elimina, escritos, etc...
  3. Los archivos temporales para las consultas grandes que no se pueden ejecutar en la memoria.

(1) sólo se necesita espacio libre a la hora de asignar más espacio para su archivo. Si su base de datos no está creciendo debe ser afectadas por el poco espacio en disco sistema de archivos. Si es que la asignación embargo, se podría pedir una muy gran parte que no encaja en ninguna lista libre usted tiene inmediatamente la fragmentación de la base de datos y causando busca cuando necesita datos para estar listo en la memoria.

(2) un ingenuo impelementation de registros donde se utiliza el sistema operativo para manejar la asignación de espacio y eliminación de sufrirá. Suponiendo que la base de datos no es de sólo lectura, habrá un flujo constante de registros, que será a menudo fragmentado en un bajo de espacio en el disco duro. En última instancia, esto hará daño a su rendimiento de escritura.

(3) base de datos tempDB, si la base de datos que necesita para la mala calidad de las consultas escritas, o no lo suficiente RAM, entonces tienes grandes problemas de poco espacio en disco causando problemas de rendimiento, ya que incluso el rendimiento de la lectura podría convertirse en el disco atado a continuación. También corre el riesgo de una interrupción si MySql necesaria para asignar espacio en disco para tempDB y el disco duro se acabó.

Acerca de las copias de seguridad...

  1. Todas las empresas que he trabajado en la guarda copias de seguridad en la misma máquina. Cuando se trata de una restauración (que se preocupa acerca de las copias de seguridad, restaura la que cuenta). Nada va a superar la velocidad de contar con el archivo de base de datos a la derecha allí en el mismo disco.
  2. Esperemos que obvio, asegúrese de que las copias de seguridad no son sólo locales.

En resumen yo diría que vas a sobrevivir a proporcionar su DB no es escribir pesado. Si es así, entonces de poco espacio en disco es un problema. Pero si yo fuera tú me gustaría trabajar en el siguiente más temprano que tarde.

  1. Confirmando tengo suficiente memoria RAM
  2. La segregación de los registros y todos los datos transitorios de tu DB.
  3. La segregación de su sistema operativo, su MySql instalar desde el resto.

El uso de ejes diferentes y controladores, si puede por 1.

Seguido por ejes diferentes

Seguido por un pobre hombre de particiones separadas.

0voto

hlosukwakha Puntos 1

Yo tuve un problema similar hace poco, cuando he usado todo el espacio en disco de uno de mis servidores de replicación. El efecto inmediato fue para la replicación de bloqueo y, a continuación, no podía iniciar sesión en MySQL debido a que el mysqld.calcetín de archivo no se pudo abrir.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: