Tengo el directorio /private/var/db/uuidtext/dsc lleno de archivos. El tamaño del directorio es >100GB y sigue creciendo constantemente. He eliminado todos los archivos e incluso he intentado reiniciar mi mac, pero no ayuda. He encontrado poca información sobre este directorio, pero parece que estos archivos son archivos de registro, pero no puedo averiguar qué proceso causa tal registro.
¿Hay alguna forma de averiguar qué causa este intenso registro?
Como se describe en mi comentario en la respuesta de @bmike, tuve problemas similares donde /private/var/db ocupaba demasiado espacio.
Para verificar cuánto espacio en disco se está utilizando, ejecutamos du en el directorio:
sudo du -h /private/var/db | sort -h
...
201M /private/var/db/uuidtext/dsc
283M /private/var/db/receipts
283M /private/var/db/audiotext
311M /private/var/db/diagnostics/Persist
422M /private/var/db/diagnostics
1,4G /private/var/dbComo borré el contenido de mi registro ayer, la carpeta "diagnostics" ya no es de 1,3G sino "solo" de 422M. Pero es claramente visible que "diagnostics" es el mayor consumidor actualmente.
Ahora podemos usar el comando log para recopilar estadísticas sobre los registros guardados en disco:
log stats --overview
== archive =============================================================
size: 428’592’976 bytes
2’076’477’945 bytes (sin comprimir)
start: Mon May 22 21:36:00 2023
end: Tue May 23 22:24:15 2023
statedump: 2’987
events: [ total log trace signpost loss ]
[ 14’820’415 12’614’086 0 1’708’567 234 ]
activity: [ create transition action ]
[ 493’988 0 522 ]
log messages: [ default info debug error fault ]
[ 10’007’820 382’093 168’182 2’168’000 1’596’558 ]
ttl: [ 1day 3days 7days 14days 30days ]
[ 16’115 267’332 244’540 1’844’891 3’868 ]
processes:
[ events (%total), decomp. bytes (%total), image UUID, image ]
[ 3’492’040 ( 23.6%), 1’132’303’470 ( 54.5%), 9B51F175-B010-360F-ADCE-ADF6DC4824E4, Citrix Viewer ]
[ 1’564’636 ( 10.6%), 146’436’706 ( 7.1%), 465422C7-3CFC-3E9F-9C04-813F3A265AA6, WindowServer ]
[ 1’559’844 ( 10.5%), 100’699’482 ( 4.8%), 6E10EA79-C562-337C-8EDD-7A33479E7B25, bluetoothd ]
[ 955’906 ( 6.4%), 96’068’735 ( 4.6%), C6D3E63E-8B9A-3C70-9836-D751398CC501, kernel ]
[ 1’072’851 ( 7.2%), 93’345’800 ( 4.5%), 7ACE5B70-4C91-32DB-9252-22E15B48D5EE, launchd ]
senders:
[ events (%total), decomp. bytes (%total), image UUID, image ]
[ 3’145’092 ( 21.2%), 1’103’917’848 ( 53.2%), 6E4B26DB-CB46-3487-B01E-A9BE22D160DF, AudioToolboxCore ]
[ 1’186’639 ( 8.0%), 119’106’238 ( 5.7%), 96676A53-B1E0-3D7E-B98B-B73873CD1880, SkyLight ]
[ 1’072’851 ( 7.2%), 93’345’800 ( 4.5%), 7ACE5B70-4C91-32DB-9252-22E15B48D5EE, launchd ]
[ 470’388 ( 3.2%), 91’912’492 ( 4.4%), F62B9AAC-1492-3A32-A6BF-77F8C26A0262, Network ]
[ 1’282’685 ( 8.7%), 64’908’843 ( 3.1%), 6E10EA79-C562-337C-8EDD-7A33479E7B25, bluetoothd ]Del resumen, podemos leer sobre el "tamaño" ocupado por los registros: en disco ~420M (=confirmado por du en la carpeta "diagnostics") y sin comprimir ~2G. También vemos la marca de tiempo del primer evento ("start") y del último evento ("end") registrado. Puedes ver que borré mi registro ayer, y que todos esos registros han sido generados en un día.
Además, en el resumen podemos encontrar los procesos que generan la mayoría de los registros: "Citrix Viewer" desencadenó 3.5M eventos de registro (que es aproximadamente el 23% de todos los registros) que ocupan 1G de memoria sin comprimir).
Por lo tanto, ahora que sabemos qué aplicación está causando el problema y debe ser investigada, queremos asegurarnos de que se libere el espacio valioso en nuestro SSD. Esto se puede hacer usando: sudo log erase --all
Esto liberará todo el espacio ocupado por /private/var/db/diagnostics.
No he encontrado una forma de eliminar el contenido en /private/var/db/uuidtext/dsc ya que volverá a aparecer inmediatamente. Esto es causado por logd o logd_helper que los mantienen abiertos y escriben constantemente en ellos. (ver la salida de sudo fs_usage -w | grep uuidtext como explicó @bmike)
Pero parece que reinstalar macOS sería una solución posible (fuente: foros de discusión de Apple y mi propia experiencia hace 9 meses, cuando instalé macOS Ventura)
Sí, la herramienta fsusage puede mostrar todas las operaciones del sistema de archivos en vivo y puedes ordenar por esa ruta para determinar qué está escribiendo y luego investigar en los detalles.
sudo fs_usage -w | grep uuidtextComo mencionas, el sistema puede autorepararse al reiniciar y actualizar. Supongo que OnyX no ayudó, pero tendremos que esperar a que vuelva a ocurrir para estar seguros.
Además, ese directorio es donde se almacenan los registros unificados, así que también podrías inspeccionar tus registros normales en la aplicación Consola - si tienes un volumen alto de registros, entonces tu crecimiento es normal y deberías desinstalar / arreglar / suprimir lo que esté generando todo ese volumen en el sistema de registro.
log stream --info --debugAdemás, la mayoría de la gente se sorprende al ver cuántos miles de mensajes de información y depuración se registran cada segundo en una Mac perfectamente saludable, así que no te preocupes si sientes que el volumen es alto sin comparar con otros ordenadores. Quizás obtener estadísticas sería un mejor indicador:
me@dev ~> log stats --overview
== archive =============================================================
size: 461,012,272 bytes
1,141,374,160 bytes (sin comprimir)
inicio: vie jul 19 06:37:25 2019
fin: dom ago 18 17:56:08 2019
dump inicial: 725
eventos: [ total registro traza signpost pérdida ]
[ 26,036,074 18,105,986 26 234,083 5 ]
actividad: [ crear transición acción ]
[ 7,694,844 0 10 ]
mensajes de registro: [ predeterminado info debug error falla ]
[ 17,799,660 219,169 105,002 215,663 601 ]
ttl: [ 1día 3días 7días 14días 30días ]
[ 0 11,021 10,620 94,679 68,285 ]
procesos:
[ eventos (%total), bytes de descompresión (%total), UUID de imagen, imagen ]
[ 4,728,900 ( 18.2%), 137,984,377 ( 12.1%), 6848C8B5-B410-3D5E-B1F5-6A289006E83F, Activity Monitor ]
[ 800,052 ( 3.1%), 100,277,357 ( 8.8%), 9C895392-8753-316E-80F0-802610ED6A2C, AssetCache ]
[ 6,498,211 ( 25.0%), 90,979,241 ( 8.0%), 26E8D205-980A-3139-B41A-BA2D40EE6294, diskarbitrationd ]
[ 12,103 ( 0.0%), 82,909,480 ( 7.3%), DF2BBC3F-1663-395D-BEA3-85172E5D5654, sandboxd ]
[ 9,827 ( 0.0%), 79,484,156 ( 7.0%), 03F25350-02B7-34AD-AF61-5001FCD85D39, sandboxd ]
remisores:
[ eventos (%total), bytes de descompresión (%total), UUID de imagen, imagen ]
[ 6,498,207 ( 25.0%), 90,979,122 ( 8.0%), 26E8D205-980A-3139-B41A-BA2D40EE6294, diskarbitrationd ]
[ 682,424 ( 2.6%), 86,726,296 ( 7.6%), 74A0A926-957A-3803-9837-CF24592E46D3, libboringssl.dylib ]
[ 145,587 ( 0.6%), 82,984,590 ( 7.3%), 6993BD8C-C535-3AD7-B511-94EABF989658, GPUWrangler ]
[ 12,027 ( 0.0%), 82,908,562 ( 7.3%), DF2BBC3F-1663-395D-BEA3-85172E5D5654, sandboxd ]
[ 9,567 ( 0.0%), 79,480,144 ( 7.0%), 03F25350-02B7-34AD-AF61-5001FCD85D39, sandboxd ]Así que 26 millones de eventos registrados en una computadora durante un mes y estuvo apagada durante 2 semanas en este mes y apenas se usó en las otras semanas. En una computadora ocupada, vería este volumen cada semana y no me preocuparía.
Acabo de resolver esto. Esto ralentizó el dispositivo hasta el punto de que había un retraso al escribir comandos y no podía actualizar el sistema antes de que el SSD se llenara por completo.
echo pffff >> dsc; sudo rm -rf /private/var/db/uuidtext/dsc; sudo cp dsc /private/var/db/uuidtext/
Mientras comandos similares fueron denegados, casi me rendí antes de este. Ahora, el monitor de actividad pasó permanentemente de escribir a 20MB/s en disco a 0/s bytes. De un 8% de la CPU del sistema a un 2%. Así que, aunque sea una solución simple, casi no hay razón para no llamarla una solución permanente. Ni siquiera usaba Mac antes, pero después de todo es UNIX.
E incluso en caso de que ya funcione, uno podría no querer los registros moderados incluso. Hasta después de que algo se rompa. Todavía podrían no valer la pena desgastar el SSD. (Ni retrasarse nunca por un momento mientras la CPU espera al SSD, incluso si debería ser raro normalmente.
Si el comando responde:
"cp: cannot overwrite directory /private/var/db/uuidtext/dsc with non-directory dsc.", entonces no se ejecutó lo suficientemente rápido, así que vuelva a intentarlo hasta que no diga nada una vez y deténgase ahí.
PD: sudo fs_usage -w | grep uuidtext solo funcionó una vez (como loco y dice que los recursos están ocupados desde que cancelé la primera ejecución).
AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.
2 votos
Por favor, añade dos informaciones: tu versión de macOS y: ¿es el tamaño realmente tan grande inmediatamente después de borrar y reiniciar?
0 votos
Utilizo Mojave 10.14.4. Después de borrar todos los registros, creó alrededor de 100-200MB/30s. Había una carga de IO enorme en el Mac, por lo que apenas se podía usar. El proceso reportcrash usaba mucha CPU, así que finalmente lo apagué. También ejecuté el OnyX para limpiar el sistema. Uno de ellos resolvió el problema después de reiniciar la máquina. Todavía no estoy seguro de qué causó el problema.