¿Por qué los DMBS no pueden confiar en el conjunto de búferes del sistema operativo?

Question

El documento de Stonebraker (Operating System Support for Database Management) explica que, "la sobrecarga para buscar un bloque del administrador del grupo de búferes por lo general incluye el de una llamada al sistema y un movimiento de núcleo a núcleo". Olvídese de la estrategia de reemplazo de búfer, etc. El único punto que cuestiono es el citado.

Tengo entendido que cuando un DBMS quiere leer un bloque x emite una instrucción de lectura común. No debe haber diferencia con la de cualquier otra aplicación que solicite una lectura.

No estoy buscando respuestas genéricas (las obtuve y leo artículos). Busco una respuesta detallada del problema descrito. Ver Does a file read from a Java application invoke a system call?

Answer 1

lectura de su otra pregunta, y trabajando hacia adelante:

Cuando el DBMS debe traer una página del disco que se implican al menos una llamada al sistema. En su punto, la mayoría de los DBMS colocan la página en su propio buffer. (También terminan en el buffer del sistema operativo, pero eso no es importante).

Entonces, tenemos una llamada al sistema. Sin embargo, podemos evitar cualquier otra llamada al sistema. Esto es posible porque el DBMS está almacenando en caché las páginas en su propio espacio de memoria. Lo primero que hará el DBMS cuando decida que necesita una página es verificar y ver si lo tiene en su caché. Si lo hace, lo recupera desde allí sin invocar una llamada al sistema.

El DBMS puede caducar las páginas en su caché de la manera que sea más beneficiosa para sus necesidades de IO. La memoria caché del sistema operativo ha expirado de una manera más general ya que el sistema operativo tiene otras cosas de qué preocuparse. Un ejemplo de esto es que un DBMS típicamente usará una gran cantidad de memoria para almacenar en caché las páginas, ya que sabe que el disco IO es una de las cosas más caras que puede hacer. El sistema operativo no hará esto, ya que tiene que equilibrar el costo del disco IO contra la memoria para el uso de otras aplicaciones.

Answer 2

La unidad de disco del sistema operativo debe generalizarse para funcionar en una variedad de situaciones. El DBMS a veces puede obtener un rendimiento significativo utilizando un código menos general que se optimiza para sus propias necesidades.

El DBMS realiza su propio almacenamiento en caché, por lo que no desea trabajar con el almacenamiento en caché de O/S. "Posee" el parche de disco, por lo que no tiene que preocuparse por compartirlo con otros procesos.

Actualización El enlace al documento es de ayuda.

En primer lugar, el papel tiene casi treinta años y se refiere a hardware obsoleto. A pesar de eso, hace una lectura bastante interesante.

En primer lugar, comprenda que el disco de E/S es un proceso en capas. Fue en 1981 y lo es aún más ahora. En el punto más bajo, un controlador de dispositivo emitirá instrucciones físicas de lectura/escritura para el hardware. Por encima de eso puede ser el código del núcleo del o/s, luego el código del espacio del usuario de o/s, luego la aplicación. Entre un fread() del programa C y las cabezas de disco en movimiento, hay al menos tres o cuatro niveles y puede ser considerablemente más. El DBMS puede tratar de mejorar el rendimiento, puede tratar de eludir algunas capas y hablar directamente con el kernel, o incluso más bajo.

Recuerdo hace algunos años la instalación de Oracle en una caja de Sun. Tenía la opción de dedicar un disco como una partición "en bruto", donde Oracle formatearía el disco de su propia manera y luego hablaría directamente con el controlador del dispositivo. El O/S no tenía acceso al disco en absoluto.

Answer 3

Es principalmente un problema de rendimiento. A dbms tiene demandas de E/S muy específicas e inusuales.

El sistema operativo puede tener cualquier cantidad de procesos realizando E/S y llenando sus almacenamientos intermedios con los datos clasificados en caché que esto produce.

Y, por supuesto, es el tema del tamaño y de lo que se almacenan en caché (un DBMS pueden ser capaces de peform mejor caché para sus necesidades de almacenamiento en caché del búfer del dispositivo más genérico).

Y luego está la cuestión de que un "bloque" genérico puede de hecho equivaler a una carga de E/S considerablemente mayor (esto depende de las particiones y cosas por el estilo) que lo que una DBM idealmente quisiera soportar; su propia memoria caché puede ajustarse para que funcione mejor con el diseño de los datos en el disco y, por lo tanto, pueda minimizar la E/S.

Una cosa más es la cuestión de los índices y medios similares para acelerar las consultas, que por supuesto funciona bastante mejor si el caché de hecho sabe lo que esto significa, en primer lugar.

Answer 4

El verdadero problema es que la memoria caché del búfer de archivos no está en el sistema de archivos utilizado por el DBMS; it's in the kernel y compartido por todos los sistemas de archivos residentes en el sistema. Cualquier memoria leída del kernel debe copiarse en el espacio del usuario: este es el movimiento de core-to-core sobre el que lee.

Más allá de esto, algunas otras razones que no se puede confiar en el grupo de búferes sistema:

1. A menudo, los DBMS de tienen una muy buena idea acerca de sus patrones de acceso próximos, y que no se pueden comunicar a estos patrones el kernel Esto puede conducir a un menor rendimiento.
2. La memoria caché de almacenamiento intermedio se almacena tradicionalmente en un rango de memoria de kernel de tamaño fijo, por lo que no puede crecer ni reducirse. Eso también significa que la memoria caché es mucho más pequeña que la memoria principal, por lo que al utilizar la memoria caché del búfer, un DBMS no podría aprovechar los recursos del sistema.

Answer 5

Sé que esto es viejo, pero salió sin respuesta.

Esencialmente:

1. El sistema operativo utiliza un espacio de direcciones separadas para cada proceso.
2. Recuperando información de cualquier otro espacio de direcciones requiere una llamada al sistema o un error de página. ** (vea a continuación)
3. El DBMS es un proceso con su propio espacio de direcciones.
4. El grupo de búferes OS que Stonebraker describe está en el espacio de direcciones del kernel.

Entonces ... para obtener datos del espacio de direcciones del kernel en el espacio de direcciones del DBMS, una llamada al sistema o un error de página es inevitable.

Tiene razón en que el acceso a los datos del administrador del grupo de búfer del sistema operativo no es más caro que una llamada de lectura normal(). (De hecho, es hecho con una lectura normal). Sin embargo, Stonebraker no está hablando de eso. Habla específicamente de las necesidades de almacenamiento en caché de DBMSes, después de, los datos se han leído del disco y están presentes en la memoria RAM.

Básicamente, él está diciendo que la memoria caché del grupo de búferes del sistema operativo es demasiado lenta para que el DBMS la use porque está almacenada en un espacio de direcciones diferente. Está sugiriendo usando un caché local en el mismo proceso (y por lo tanto el mismo espacio de direcciones), lo que puede darle una aceleración significativa para aplicaciones como DBMSes que golpean mucho el caché, porque eliminará esa sobrecarga de syscall.

Aquí está el punto exacto en el que se explica el uso de una caché local en el mismo proceso:

Sin embargo, muchos DBMS incluyendo INGRES [20] y el Sistema R [4] optar por poner un DBMS búfer administrados grupo en el espacio de usuario para reducir la sobrecarga. Por lo tanto, cada uno de estos sistemas ha ido al problema de construir su propio administrador de grupo de búfer para mejorar el rendimiento de .

También menciona los problemas de múltiples núcleos en el extracto se cita anteriormente. Aquí se aplican efectos similares, porque si puede tener solo un caché por núcleo, puede puede ser capaz de evitar las ralentizaciones de los caché de la CPU cuando varias CPU están leyendo y escribiendo los mismos datos.

** Por cierto, creo que el artículo de Stonebraker de 1981 es en realidad pre-mmap. Él lo menciona como un trabajo futuro. "La tendencia a proporcionar el sistema de archivos como parte de la memoria virtual compartida (por ejemplo, Pilot [16]) puede proporcionar una solución a este problema".