¿Cuál es el estado de POSIX asynchronous I/O (AIO)?
Hay páginas dispersas por la web que describen las instalaciones de POSIX AIO en diferentes cantidades de detalle. Ninguno de ellos es terriblemente reciente. No está claro qué, exactamente, están describiendo. Por ejemplo, el "oficial" (?) sitio web para el kernel de Linux soporte de E/S asíncrono aquí dice que los sockets no funcionan, pero el "aio.h " las páginas de manual en mi estación de trabajo Ubuntu 8.04.1 parecen implicar que funciona para descriptores de archivos arbitrarios. Luego hay otro proyecto que parece funcionar en la capa de biblioteca con aún menos documentación.
Me gustaría saber:
- ¿Cuál es el propósito de POSIX AIO? Dado que el ejemplo más obvio de una implementación que puedo encontrar dice que no soporta sockets, todo me parece raro. ¿Es solo para E / S de disco asincrónico? Si es así, ¿por qué la API hiper-general? Si no, ¿por qué es el disco I/O la primera cosa que fue atacada?
- ¿Dónde están los ejemplos completar POSIX AIO programas que I puede mirar?
- ¿Alguien realmente lo usa, de verdad?
- ¿Qué plataformas soportan POSIX AIO? ¿Qué partes de ella soportan? ¿Alguien realmente apoya la implícita "Cualquier E / S a cualquier FD" que
<aio.h>parece prometer?
Los otros mecanismos de multiplexación disponibles para mí son perfectamente buenos, pero los fragmentos aleatorios de información flotando por ahí me han hecho curioso.
4 answers
La E/S de red no es una prioridad para AIO porque todos los que escriben servidores de red POSIX utilizan un enfoque basado en eventos y sin bloqueo. El viejo estilo de Java "miles de millones de hilos de bloqueo" enfoque apesta horriblemente.
Las E/S de escritura de disco ya están almacenadas en búfer y las E/S de lectura de disco se pueden preestablecer en búfer usando funciones como posix_fadvise. Eso deja E/S de disco directo y sin búfer como el único propósito útil para AIO.
La E/S directa sin búfer solo es realmente útil para transacciones bases de datos, y esas tienden a escribir sus propios subprocesos o procesos para administrar sus E/S de disco.
Entonces, al final eso deja a POSIX AIO en la posición de no servir ningún propósito útil. No lo uses.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-09-17 23:15:51
Hacer E/S de socket de manera eficiente se ha resuelto con kqueue, epoll, puertos de finalización de IO y similares. Hacer E/S de archivos asincrónicos es una especie de regreso tardío (aparte de las E/S superpuestas de Windows y el soporte temprano de solaris para posix AIO).
Si está buscando hacer E/S de socket, probablemente sea mejor usar uno de los mecanismos anteriores.
El propósito principal de AIO es, por lo tanto, resolver el problema de E / S de disco asíncrono. archivos regulares, y no sockets (ya que kqueue lo hace mucho mejor de todos modos).
Las operaciones de escritura suelen ser almacenadas en caché por el núcleo y eliminadas posteriormente. Por ejemplo, cuando la cabeza de lectura de la unidad pasa por la ubicación donde se va a escribir el bloque.
Sin embargo, para las operaciones de lectura, si desea que el núcleo priorice y ordene sus lecturas, AIO es realmente la única opción. He aquí por qué el kernal puede (teóricamente) hacerlo mejor que cualquier nivel de usuario solicitud:
- El núcleo ve todas las E/S de disco, no solo los trabajos de disco de sus aplicaciones, y puede ordenarlos a nivel global
- El núcleo (puede) saber dónde está el cabezal de lectura del disco, y puede seleccionar los trabajos de lectura que le pase en orden óptimo, para mover el cabezal la distancia más corta
- El núcleo puede aprovechar cola de comandos nativa para optimizar aún más sus operaciones de lectura
- Es posible que pueda emitir más operaciones de lectura por llamada al sistema usando lio_listio () que con readv (), especialmente si sus lecturas no son (lógicamente) contiguas, ahorrando un poco de sobrecarga de llamadas al sistema.
- Su programa puede ser un poco más simple con AIO ya que no necesita un hilo adicional para bloquear una llamada de lectura o escritura.
Dicho esto, posix AIO tiene una interfaz bastante incómoda, por ejemplo:
- El único medio eficiente y bien soportado de devoluciones de llamada de eventos son las señales via, lo que hace que sea difícil de usar en un biblioteca, ya que significa usar números de señal del espacio de nombres de señal process-global. Si su sistema operativo no admite señales en tiempo real, también significa que debe recorrer todas sus solicitudes pendientes para averiguar cuál terminó realmente (este es el caso de Mac OS X, por ejemplo, no Linux). La captura de señales en un entorno multihilo también crea algunas restricciones complicadas. Normalmente no puede reaccionar al evento dentro del manejador de señal, pero tiene que elevar una señal, escribir en una canalización o uso de signalfd () (en linux).
- lio_suspend() tiene los mismos problemas que select (), no se escala muy bien con el número de trabajos.
- lio_listio(), tal como está implementado, tiene un número bastante limitado de trabajos que puede pasar, y no es trivial encontrar este límite de una manera portátil. Tienes que llamar a sysconf (_SC_AIO_LISTIO_MAX), que puede fallar, en cuyo caso puedes usar el AIO_LISTIO_MAX define, que no está necesariamente definido, pero luego puedes usar 2, que está definido como garantizado para ser apoyado.
En cuanto a la aplicación del mundo real que utiliza posix AIO, puede echar un vistazo a lighttpd (lighty), que también publicó una medición de rendimiento al introducir el soporte.
La mayoría de las plataformas posix soportan posix AIO por ahora (Linux, BSD, Solaris, AIX, tru64). Windows lo admite a través de su E/S de archivo superpuesto.Mi entendimiento es que solo Solaris, Windows y Linux realmente admiten async. E / S de archivo todo el camino hasta el controlador, mientras que el otro Los sistemas operativos emulan la asincronía. E / S con hilos de kernel. Linux es la excepción, su implementación posix AIO en glibc emula operaciones asíncronas con subprocesos a nivel de usuario, mientras que su interfaz asíncrona de E/S nativa (io_submit (), etc.) son verdaderamente asíncronos hasta el controlador, suponiendo que el controlador lo soporte.
Creo que es bastante común entre los sistemas operativos no soportar posix AIO para cualquier fd, pero restringirlo a archivos regulares.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-03-23 01:11:22
Un desarrollador de libtorrent proporciona un informe sobre esto: http://blog.libtorrent.org/2012/10/asynchronous-disk-io /
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-11-20 04:15:36
Hay aio_write - implementado en glibc; la primera llamada de la función aio_read o aio_write genera una serie de hilos de modo de usuario, aio_write o aio_read post peticiones a ese hilo, el hilo hace pread/pwrite y cuando se termina la respuesta se publica de nuevo al hilo de llamada bloqueado.
Ther también es' real ' aio - soportado por el nivel del kernel (necesita libaio para eso, vea la llamada io_submit http://linux.die.net/man/2/io_submit ); también necesita O_DIRECT para eso (también puede que no sea compatible con todos los sistemas de archivos, pero los principales sí lo son)
Ver aquí:
Http://lse.sourceforge.net/io/aio.html
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-23 12:10:30