r - too - what is the seo title
Error: se alcanzó el número máximo de DLL (4)
A partir de R 3.4, puede establecer un número máximo diferente de DLL utilizando una variable de entorno R_MAX_NUM_DLLS . De las notas de publicación:
El número máximo de DLL que se pueden cargar en R, por ejemplo, a través de dyn.load () ahora se puede aumentar configurando la variable de entorno R_MAX_NUM_DLLS antes de iniciar R.
Estoy escribiendo un paquete R que depende de muchos otros paquetes. Cuando cargué demasiados paquetes en la sesión, frecuentemente recibí este error:
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared object ''/Library/Frameworks/R.framework/Versions/3.2/Resources/library/proxy/libs/proxy.so'':
`maximal number of DLLs reached...
Esta publicación superó el número máximo de DLL en R señaló que el problema es con el Rdynload.c del código base de R: #define MAX_NUM_DLLS 100
¿Hay alguna forma de evitar este problema, excepto la modificación y la creación desde la fuente?
El aumento de ese número es, por supuesto, "posible" ... pero también cuesta un poco (lo que se suma a la huella de memoria fija de R).
No establecí ese límite, pero estoy bastante seguro de que también fue un recordatorio para que useR "limpie" un poco en su sesión de R, es decir, no cargue espacios de nombres de paquetes innecesariamente. Todavía no puedo imaginar que necesites> 100 paquetes | espacios de nombres cargados en su sesión R. OTOH, algunos paquetes hoy en día tienen una gran cantidad de dependencias, por lo que estoy de acuerdo en que esto al menos puede ocurrir accidentalmente con más frecuencia que en el pasado.
Por supuesto, la solución real sería una mejora de código que comience con un número relativamente pequeño de estructuras "DLLinfo" (por ejemplo, 32) y luego asigne más lotes (de tamaño, por ejemplo, 32) si es necesario.
¡Los parches a las fuentes de R (tronco de desarrollo en subversion en https://svn.r-project.org/R/trunk/ ) son muy bienvenidos!
---- agregado el 26 de enero de 2017: mientras tanto, hemos tenido un informe de error público sobre esto, un parche propuesto (que no fue lo suficientemente bueno: siempre hay un límite dependiente del sistema operativo en el número de archivos abiertos) ), y hoy ese informe de error ha sido cerrado por el miembro central de R @TomasKalibera, quien implementó un nuevo código donde se establece el número máximo de DLL cargadas en
pmax(100, pmin(1000, 0.6* OS_dependent_getrlimit_or_equivalent()))
y así en Windows y Linux (y aún no probado, pero "casi seguramente" macOS), el límite debería ser considerablemente más alto que antes.
----- Actualización # 2 (escrita el 5 de enero de 2018):
En Oct''17, el cambio anterior se hizo más automático con el siguiente compromiso con las fuentes (de la versión de desarrollo de R - ¡solo!)
r73545 | kalibera | 2017-10-12 14:41:20
Aumente el número de DLL que se pueden cargar de forma predeterminada. Si es necesario, aumente el límite suave en archivos abiertos.
y en la página de ayuda ?dyn.load ( https://stat.ethz.ch/R-manual/R-devel/library/base/html/dynload.html ) ahora se menciona el ulimit -n <num_open_files> (sección Tenga en cuenta cerca de la parte inferior).
Por lo tanto, podría considerar usar la versión de desarrollo de R hasta que se convierta en "flujo principal" en abril.
Alternativamente, lo haces (en un terminal / shell)
ulimit -n 2048
y luego iniciar R desde ese terminal. Tomas Kalibera mencionó esto para trabajar en macOS.
Es fácil ir a la variable de entorno y editar
variable_name = R_MAX_NUM_DLL
value = 1000
Reinicio R funcionó bien para mí
Tuve este problema con la biblioteca simpleSingleCell en bioconductor
En el macOS no puedes exceder de 256. Así que puse mi .Renviron en mi directorio de casa R_MAX_NUM_DLLS = 150