[opensuse-es] Samba lento pero en una sola comparticion
Ver 3.6.19 4 discos en RAID 5 4 directorios y en samba 4 comparticiones para montar 4 unidades de red todas tiene la misma configuracion de samba Ahora lo curioso : 3 comparticiones la velocidad con windows es normal la 4 se esta muriendo, te puedes morir antes de que acabe de borrar o grabar algo. La lectura funciona bien. Si alguno tiene alguna idea la pase antes de que le pegue fuego :) Saludos -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) 2013/10/25 Francisco F. <admin-listas@satel-sa.com>
Ver 3.6.19
4 discos en RAID 5
¿Tipos de disco? ¿RAID por SW o por HW? Si es por HW, ¿qué controladora HW?
4 directorios y en samba 4 comparticiones para montar 4 unidades de red todas tiene la misma configuracion de samba
¿Tamaño de los ficheros? ¿Número de ficheros? ¿Sistema de ficehros? ¿Tipo de datos (BBDD o no)? ¿Número de usuarios por share? ¿Configuración de Samba? ¿Usas jumbo frames? ¿Cuántas tarjetas de red? ¿Comparten las t. de red bus PCI con otro dispositivo (tarjeta RAID)? ¿CPU y RAM? ¿El sistema operativo está en ese mismo RAID 5? ¿Qué otras aplicaciones/servicios tienes corriendo (Web, BBDD, correo, ...?
Ahora lo curioso : 3 comparticiones la velocidad con windows es normal
la 4 se esta muriendo, te puedes morir antes de que acabe de borrar o grabar algo. La lectura funciona bien.
Borrar es un proceso lento de metadatos, implica bastante IOPs. Si encima tienes muchos ficheros ... peor. A la hora de guardar un dato, el RAID 5 tiene que hacer un R/M/W (read/modify/write). Es decir, leer el bloque, modificar la paridad y escribirlo. 3 operaciones de I/O ... muy costoso. En un RAID (3, 4, 5 ó 6), la lectura es generalmente el doble que la escritura.
Si alguno tiene alguna idea la pase antes de que le pegue fuego :)
Primero deberías probar cada disco (hdparm), luego pruebas el RAID con el sistema de ficheros (bonnie, ...) y luego pruebas la red (iperf). Necesitaríamos más datos. Pero MHO es que tienes 3 opciones: - tienes diferentes tipos de acceso y hace que "compitan" por los recursos. - el RAID 5 no es la configuración ideal para el tipo de acceso de la aplicación o usuario que accede al share problemático - las dos opciones anteriores son ciertas ;) HTH Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 25/10/2013 22:22, Rafa Griman escribió:
Hola :)
2013/10/25 Francisco F. <admin-listas@satel-sa.com>
Ver 3.6.19
4 discos en RAID 5
¿Tipos de disco?
¿RAID por SW o por HW?
Si es por HW, ¿qué controladora HW?
4 directorios y en samba 4 comparticiones para montar 4 unidades de red todas tiene la misma configuracion de samba
¿Tamaño de los ficheros?
Jajajaj, Tan quisquilloso como siempre con los detalles :) cualquier tamaño
¿Número de ficheros?
de 1 a 1000, los que quieras
¿Sistema de ficheros?
XFS
¿Tipo de datos (BBDD o no)?
Normales, dic, xls, jpg, dwg, vamos cualquier fichero
¿Número de usuarios por share?
ilimitado no somos muchos
¿Configuración de Samba?
¿Usas jumbo frames?
No, lo tengo desactivado en todos lados Si no lo tienes bien pulido da mas problemas que resuelve
¿Cuántas tarjetas de red? 1
¿Comparten las t. de red bus PCI con otro dispositivo (tarjeta RAID)? No
¿CPU y RAM?
2 xeon dual core 4gb sobran casi todos
¿El sistema operativo está en ese mismo RAID 5?
No
¿Qué otras aplicaciones/servicios tienes corriendo (Web, BBDD, correo, ...?
Da igual, si las apago sigue haciendo lo mismo
Ahora lo curioso : 3 comparticiones la velocidad con windows es normal
la 4 se esta muriendo, te puedes morir antes de que acabe de borrar o grabar algo. La lectura funciona bien.
Borrar es un proceso lento de metadatos, implica bastante IOPs. Si encima tienes muchos ficheros ... peor.
Si, pero porque solo con una comparticion de las 4 que tiene y que usan el mismo disco
A la hora de guardar un dato, el RAID 5 tiene que hacer un R/M/W (read/modify/write). Es decir, leer el bloque, modificar la paridad y escribirlo. 3 operaciones de I/O ... muy costoso.
En un RAID (3, 4, 5 ó 6), la lectura es generalmente el doble que la escritura.
El raid va bien con las otras comparticiones y en nfs
Si alguno tiene alguna idea la pase antes de que le pegue fuego :)
Primero deberías probar cada disco (hdparm), luego pruebas el RAID con el sistema de ficheros (bonnie, ...) y luego pruebas la red (iperf).
Necesitaríamos más datos. Pero MHO es que tienes 3 opciones: - tienes diferentes tipos de acceso y hace que "compitan" por los recursos. - el RAID 5 no es la configuración ideal para el tipo de acceso de la aplicación o usuario que accede al share problemático
Esta reprobado que va bien todo eso.
- las dos opciones anteriores son ciertas ;)
HTH
Rafa
En fin que me suena a algun dato de "cache" del samba pero no consigo encontrar solucion. saludos -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) 2013/10/23 admin-listas <admin-listas@satel-sa.com>:
El 25/10/2013 22:22, Rafa Griman escribió:
Hola :)
2013/10/25 Francisco F. <admin-listas@satel-sa.com>
Ver 3.6.19
4 discos en RAID 5
¿Tipos de disco?
¿RAID por SW o por HW?
Si es por HW, ¿qué controladora HW?
4 directorios y en samba 4 comparticiones para montar 4 unidades de red todas tiene la misma configuracion de samba
¿Tamaño de los ficheros?
Jajajaj, Tan quisquilloso como siempre con los detalles :)
cualquier tamaño
No me lo creo ;) ¿Tienes ficheros de 1 byte _y_ ficheros de hasta 2 PB? ;) Vamos a ser algo más específicos, si consideras ficheros grandes a los de 5 MBytes o mayor ...
¿Número de ficheros?
de 1 a 1000, los que quieras
No da o mismo. Si tienes un share con 1 fichero y otro share con 1000 ficheros ... el segundo va a sufrir mucho aún con un simple ls. Deberías intentar equilibrar shares.
¿Sistema de ficheros?
XFS
Si usas XFS y tienes problemas de metadatos (que es lo que parece), puedes solucionarlo poniendo un disco adicional (bueno, 2 discos en RAID 1) y poner el journal en ese nuevo RAID 1. Esto no es la solución perfecta ya que tendrías que hacer más cosas, pero algo aliviaría. Otra cosa, por norma general, XFS te detecta el RAID (stripe unit y stripe width), aunque hay veces que no. Lo ideal es que sea igual en ambos casos (RAID y XFS). Otra cosa a tener en cuenta es si las particiones están "aligned", esto puede dar problemas de rendimiento también.
¿Tipo de datos (BBDD o no)?
Normales, dic, xls, jpg, dwg, vamos cualquier fichero
Define "normales" ;) Volvemos a lo de antes: ¿tamaño de los ficheros y acceso/comportamiento?
¿Número de usuarios por share?
ilimitado
no somos muchos
Si no sois muchos ... no es ilimitado ;) Define muchos ... el hardware puede tener otra definición de "no muchos".
¿Configuración de Samba?
¿Usas jumbo frames?
No, lo tengo desactivado en todos lados Si no lo tienes bien pulido da mas problemas que resuelve
Por eso lo preguntaba.
¿Cuántas tarjetas de red?
1
¿Comparten las t. de red bus PCI con otro dispositivo (tarjeta RAID)?
No
¿CPU y RAM?
2 xeon dual core
4gb sobran casi todos
Si sobran casi todos, el Linux no cachea ... luego estás haciendo acceso aleatorio a disco, esto castiga mucho los discos: tenías que haber elegido otro tipo de RAID (por ejemplo, RAID 10 ... ojo, no digo RAID 0+1, digo RAID 10). ¿Qué frecuencia? Dices que no tienes Jumbo frames luego se está produciendo muchos context switching: esto castiga mucho a la CPU y reduce el rendimiento. Aunque en tu caso sigo pensando que es un problema de acceso aleatorio e IOPS ... que también puede castigar mucho a la CPU si los ficheors son muy pequeños.
¿El sistema operativo está en ese mismo RAID 5?
No
Menos mal ;)
¿Qué otras aplicaciones/servicios tienes corriendo (Web, BBDD, correo, ...?
Da igual, si las apago sigue haciendo lo mismo
Eso que nos quitamos de encima :)
Ahora lo curioso : 3 comparticiones la velocidad con windows es normal
la 4 se esta muriendo, te puedes morir antes de que acabe de borrar o grabar algo. La lectura funciona bien.
Borrar es un proceso lento de metadatos, implica bastante IOPs. Si encima tienes muchos ficheros ... peor.
Si, pero porque solo con una comparticion de las 4 que tiene y que usan el mismo disco
Pero ese share puede que tenga más metadatos que la otra (más ficheros). Según dices antes, de los 4 GB te sobran casi todos: no cachea, haces mucho IO y muy aleatorio. No hay "read ahead", no hay cacheo, no hay buffering. Otra cosa, XFS se desarrolló para máquinas con mucha RAM, y muy buen sistema de IO y CPU. Si esl sistema está limitado (sobre todo en RAM), te va dar problemas de rendimiento. XFS trabaja todo lo que puede en RAM, IOW, si le dices que borre 1000 ficheros, no empieza a borrar en el momento que encuentra el primer fichero, analiza todo (en RAM) y luego borra. Si en los otros shares esto no ocurre ... es porque tienen menos ficheros. No es lo mismo para XFS borrar un directorio con 1 fichero que uno con 1000 ficheros.
A la hora de guardar un dato, el RAID 5 tiene que hacer un R/M/W (read/modify/write). Es decir, leer el bloque, modificar la paridad y escribirlo. 3 operaciones de I/O ... muy costoso.
En un RAID (3, 4, 5 ó 6), la lectura es generalmente el doble que la escritura.
El raid va bien con las otras comparticiones y en nfs
¿Mezclas NFS y SMB? ¿Con los mismos datos? Me refiero a que si un mismo fichero (directorio o no) los compartes tanto con NFS como con SMB. NO lo hagas. Otra cosa, ¿cuándo NFS tienes corriendo? Teóricamente cuantos más tengas corriendo, mejor funciona ... pero más recursos consume por lo que llega un momento que se estanca. No me vale comparar NFS con CIFS sin conocer las configuraciones. No me vale comparar 2 shares si no sé el tipo y número de ficheros que contienen. Es como decir coche A es mejor que el B ... y resulta que no sabes ni cuál es el A ni cuál es el B ni en qué condiciones se han comparado. Te recomiendo que monitorices CPU, RAM y IO al igual que el número de ficheros de cada share.
Si alguno tiene alguna idea la pase antes de que le pegue fuego :)
Primero deberías probar cada disco (hdparm), luego pruebas el RAID con el sistema de ficheros (bonnie, ...) y luego pruebas la red (iperf).
Necesitaríamos más datos. Pero MHO es que tienes 3 opciones: - tienes diferentes tipos de acceso y hace que "compitan" por los recursos. - el RAID 5 no es la configuración ideal para el tipo de acceso de la aplicación o usuario que accede al share problemático
Esta reprobado que va bien todo eso.
¿El qué va bien? Y ¿cómo lo has comprobado y demostrado? Lo pregunto porque no he visto datos/resultados de monitorización. Si lo que dices de la RAM es cierto, demuestra lo contrario: el RAID utilizado es el incorrecto. A menos que tengas otros problemas que impidan que el Linux llene la RAM (caching). ¿Has monitorizado el sistema (RAM, IOPS, CPU)? Te podría ayudar a encontrar el problema ;)
- las dos opciones anteriores son ciertas ;)
HTH
Rafa
En fin que me suena a algun dato de "cache" del samba pero no consigo encontrar solucion.
No nos has mostrado la configuración de Samba. Si es algo "compleja", mi consejo es quitar todo lo que "mejora el rendimiento" porque muchas veces depende de parámetros del kernel, el driver de red, ... HTH Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2013-10-26 a las 22:49 +0200, Rafa Griman escribió:
Otra cosa a tener en cuenta es si las particiones están "aligned", esto puede dar problemas de rendimiento también.
Eso me recuerda: si es un disco nuevo con sectores de... 4K, creo que es, hay que particionar con gparted u otro que alinee en megabytes, no en sectores. Si se hace mal el disco se vuelve muy lento. Si una particion está mal alineada, esa partición es lenta.
reduce el rendimiento. Aunque en tu caso sigo pensando que es un problema de acceso aleatorio e IOPS ... que también puede castigar mucho a la CPU si los ficheors son muy pequeños.
He hecho unas pruebas tontas estos dias. Me he puesto a escribir ficheros de 100 bytes en un directorio de distintos tipos de sistemas de ficheros. XFS se porta bien, pero el reiserfs aguanta millones de esos ficheros, muchísimo más que cualquier otro. El btrfs peta. Literalmente, puedes tirar abajo el kernel y la partición. Como usuario, sin ser root.
Otra cosa, XFS se desarrolló para máquinas con mucha RAM, y muy buen sistema de IO y CPU. Si esl sistema está limitado (sobre todo en RAM), te va dar problemas de rendimiento. XFS trabaja todo lo que puede en RAM, IOW, si le dices que borre 1000 ficheros, no empieza a borrar en el momento que encuentra el primer fichero, analiza todo (en RAM) y luego borra.
Ah... curioso. Eso explica algunas cosas.
El raid va bien con las otras comparticiones y en nfs
¿Mezclas NFS y SMB? ¿Con los mismos datos? Me refiero a que si un mismo fichero (directorio o no) los compartes tanto con NFS como con SMB. NO lo hagas.
¿Y eso? :-? - -- Saludos Carlos E. R. (desde 12.3 x86_64 "Dartmouth" en Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJsNkoACgkQtTMYHG2NR9VQDACdHEUP/QnOEdDDT/t/3a99GXig BfcAoJLperV6L6ladBsCVcwxhOupHqsr =yPtq -----END PGP SIGNATURE-----
Hola :) 2013/10/26 Carlos E. R. <robin.listas@telefonica.net>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2013-10-26 a las 22:49 +0200, Rafa Griman escribió:
[...]
¿Mezclas NFS y SMB? ¿Con los mismos datos? Me refiero a que si un mismo fichero (directorio o no) los compartes tanto con NFS como con SMB. NO lo hagas.
¿Y eso? :-?
Porque no se "avisan" que tienen el fichero bloqueado. Ejemplo: si en Windows dos personas abren un fichero que se encuentra en un servidor, al segundo tipo le aparecerá un mensaje en pantalla de: "Fulano_1 tiene abierto el fichero. ¿Desea abrirlo en sólo lectura o hacer una copia local?" ... Bueno, algo así sale, no me sé el mensaje real O:) Bueno, pues si Fulano_1 abre el fichero mediante NFS ... para SMB ese fichero no está bloqueado por lo que dejará a Fulano_2 abrirlo = corrupción de datos. El sistema operativo sabe que el fichero está abierto (lo puedes comprobar con fuser o lsof), pero el servidor (NFS o Samba) no sabe que el ficerho está bloqueado porque no "conocen" los bloqueos que hace el otro. HTH Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2013-10-27 a las 22:16 +0100, Rafa Griman escribió:
Hola :)
El 2013-10-26 a las 22:49 +0200, Rafa Griman escribió:
[...]
¿Mezclas NFS y SMB? ¿Con los mismos datos? Me refiero a que si un mismo fichero (directorio o no) los compartes tanto con NFS como con SMB. NO lo hagas.
¿Y eso? :-?
Porque no se "avisan" que tienen el fichero bloqueado.
¡Anda!
Ejemplo: si en Windows dos personas abren un fichero que se encuentra en un servidor, al segundo tipo le aparecerá un mensaje en pantalla de:
"Fulano_1 tiene abierto el fichero. ¿Desea abrirlo en sólo lectura o hacer una copia local?"
... Bueno, algo así sale, no me sé el mensaje real O:)
Si, el Windows tiene definido y documentado la compartición de ficheros desde quizás el MsDOS 4.0, con bloqueos forzados por el sistema, no voluntario. No necesita ficheros bandera. En MsDOS, e imagino que el Windows lo sigue soportando, podías bloquear una region de un fichero. Podías decir que una zona del fichero estaba en lectura/escritura, mientras otras zonas estaban accesible para sólo lectura.
Bueno, pues si Fulano_1 abre el fichero mediante NFS ... para SMB ese fichero no está bloqueado por lo que dejará a Fulano_2 abrirlo = corrupción de datos.
¡Arrea! :-O
El sistema operativo sabe que el fichero está abierto (lo puedes comprobar con fuser o lsof), pero el servidor (NFS o Samba) no sabe que el ficerho está bloqueado porque no "conocen" los bloqueos que hace el otro.
Vaya fallo... - -- Saludos Carlos E. R. (desde 12.3 x86_64 "Dartmouth" en Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJtiAcACgkQtTMYHG2NR9W05wCeLxi0cO28avIKPUeuTzPmFoF5 Y14An2LGoYh+eOBJB0GU+bTVftUWwPoI =c1oP -----END PGP SIGNATURE-----
Hola :) 2013/10/27 Carlos E. R. <robin.listas@telefonica.net>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2013-10-27 a las 22:16 +0100, Rafa Griman escribió:
Hola :)
El 2013-10-26 a las 22:49 +0200, Rafa Griman escribió:
[...]
¿Mezclas NFS y SMB? ¿Con los mismos datos? Me refiero a que si un mismo fichero (directorio o no) los compartes tanto con NFS como con SMB. NO lo hagas.
¿Y eso? :-?
Porque no se "avisan" que tienen el fichero bloqueado.
¡Anda!
Ejemplo: si en Windows dos personas abren un fichero que se encuentra en un servidor, al segundo tipo le aparecerá un mensaje en pantalla de:
"Fulano_1 tiene abierto el fichero. ¿Desea abrirlo en sólo lectura o hacer una copia local?"
... Bueno, algo así sale, no me sé el mensaje real O:)
Si, el Windows tiene definido y documentado la compartición de ficheros desde quizás el MsDOS 4.0, con bloqueos forzados por el sistema, no voluntario. No necesita ficheros bandera.
En MsDOS, e imagino que el Windows lo sigue soportando, podías bloquear una region de un fichero. Podías decir que una zona del fichero estaba en lectura/escritura, mientras otras zonas estaban accesible para sólo lectura.
Sí, lo que no me acuerdo es cómo se llama O;) Esto ahora se está poniendo de moda en los sistemas de ficheros basados en objetos. Abres un objeto (parte del fichero, mientras que el resto no lo tocas.
Bueno, pues si Fulano_1 abre el fichero mediante NFS ... para SMB ese fichero no está bloqueado por lo que dejará a Fulano_2 abrirlo = corrupción de datos.
¡Arrea! :-O
El sistema operativo sabe que el fichero está abierto (lo puedes comprobar con fuser o lsof), pero el servidor (NFS o Samba) no sabe que el ficerho está bloqueado porque no "conocen" los bloqueos que hace el otro.
Vaya fallo...
No es realmente un fallo ... es que son dos estándares diferentes y cada uno va por su lado. Estaría bien que dijeran: "Vamos a definir el bloqueo de ficheros de esta manera ..." Pues si eso te parece un fallo (mejor dicho: engorroso) ... no te quiero contar el tema de permisos ... HTH Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2013-10-27 a las 23:18 +0100, Rafa Griman escribió:
Hola :)
2013/10/27 Carlos E. R. <>:
Si, el Windows tiene definido y documentado la compartición de ficheros desde quizás el MsDOS 4.0, con bloqueos forzados por el sistema, no voluntario. No necesita ficheros bandera.
En MsDOS, e imagino que el Windows lo sigue soportando, podías bloquear una region de un fichero. Podías decir que una zona del fichero estaba en lectura/escritura, mientras otras zonas estaban accesible para sólo lectura.
Sí, lo que no me acuerdo es cómo se llama O;) Esto ahora se está poniendo de moda en los sistemas de ficheros basados en objetos. Abres un objeto (parte del fichero, mientras que el resto no lo tocas.
Te lo puedo buscar - tengo el manual de referencia del msdos 5, ahí viene entero. :-) Es el mecanismo que usaba el Access (digo usaba porque no se lo que hacen ahora). No era un sistema cliente servidor, sino un fichero que podía ser accessado por uno o varios programas "access", en el mismo o distintos ordernadores en red. De esa manera, sin ser cliente-servidor era posible accesar la misma base de datos desde distintos ordenadores y cambiar simultaneamente diferentes registros, sobre el mismo fichero base en uno de los ordenadores. Tengo mis sospechas que el samba no soporta este sistema de bloqueo. Sólo sospechas.
Bueno, pues si Fulano_1 abre el fichero mediante NFS ... para SMB ese fichero no está bloqueado por lo que dejará a Fulano_2 abrirlo = corrupción de datos.
¡Arrea! :-O
El sistema operativo sabe que el fichero está abierto (lo puedes comprobar con fuser o lsof), pero el servidor (NFS o Samba) no sabe que el ficerho está bloqueado porque no "conocen" los bloqueos que hace el otro.
Vaya fallo...
No es realmente un fallo ... es que son dos estándares diferentes y cada uno va por su lado. Estaría bien que dijeran: "Vamos a definir el bloqueo de ficheros de esta manera ..."
Desde mi punto de vista es un fallo. Llevo lustros pensando que el sistema de compartición y bloqueo de ficheros en Linux es defectuoso. Porque se usan varios estandares, y el bloqueo por el kernel ha llegado tarde y no todos lo usan.
Pues si eso te parece un fallo (mejor dicho: engorroso) ... no te quiero contar el tema de permisos ...
Calla, calla. El samba la lia gorda porque tiene que hablar hacia afuera con los permisos estilo Windows, y hacia adentro con los permisos estilo Linux... - -- Saludos Carlos E. R. (desde 12.3 x86_64 "Dartmouth" en Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJtmNQACgkQtTMYHG2NR9WmSQCfX5C+/iXisHCzkjCbJcizgwys 908AnRJg3uqQqIFyO3BTf7mjzqLrhvGe =VTD+ -----END PGP SIGNATURE-----
Hola :) 2013/10/27 Carlos E. R. <robin.listas@telefonica.net>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2013-10-27 a las 23:18 +0100, Rafa Griman escribió:
Hola :)
2013/10/27 Carlos E. R. <>:
Si, el Windows tiene definido y documentado la compartición de ficheros desde quizás el MsDOS 4.0, con bloqueos forzados por el sistema, no voluntario. No necesita ficheros bandera.
En MsDOS, e imagino que el Windows lo sigue soportando, podías bloquear una region de un fichero. Podías decir que una zona del fichero estaba en lectura/escritura, mientras otras zonas estaban accesible para sólo lectura.
Sí, lo que no me acuerdo es cómo se llama O;) Esto ahora se está poniendo de moda en los sistemas de ficheros basados en objetos. Abres un objeto (parte del fichero, mientras que el resto no lo tocas.
Te lo puedo buscar - tengo el manual de referencia del msdos 5, ahí viene entero. :-)
Si mal no recuerdo, en la documentación de Samba aparece.
Es el mecanismo que usaba el Access (digo usaba porque no se lo que hacen ahora). No era un sistema cliente servidor, sino un fichero que podía ser accessado por uno o varios programas "access", en el mismo o distintos ordernadores en red. De esa manera, sin ser cliente-servidor era posible accesar la misma base de datos desde distintos ordenadores y cambiar simultaneamente diferentes registros, sobre el mismo fichero base en uno de los ordenadores.
Tengo mis sospechas que el samba no soporta este sistema de bloqueo. Sólo sospechas.
IIRC, sí lo soporta ... ahora claro, mi RAM no es lo que era ;) [...]
No es realmente un fallo ... es que son dos estándares diferentes y cada uno va por su lado. Estaría bien que dijeran: "Vamos a definir el bloqueo de ficheros de esta manera ..."
Desde mi punto de vista es un fallo. Llevo lustros pensando que el sistema de compartición y bloqueo de ficheros en Linux es defectuoso. Porque se usan varios estandares, y el bloqueo por el kernel ha llegado tarde y no todos lo usan.
Pues si eso te parece un fallo (mejor dicho: engorroso) ... no te quiero contar el tema de permisos ...
Calla, calla.
El samba la lia gorda porque tiene que hablar hacia afuera con los permisos estilo Windows, y hacia adentro con los permisos estilo Linux...
A eso me refiero ;) Es un jaleo inmenso. Me he leído bastantes documentos al respecto y no veas el jaleo que monta el Windows (y que intenta imitar el Samba). En teoría, con NFS v4 también han querido adoptar esas mejoras que ofrece SMB v2. <sigh> ... KISS ... <sigh> Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) Se me olvidaba ... 2013/10/26 Carlos E. R. <robin.listas@telefonica.net>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2013-10-26 a las 22:49 +0200, Rafa Griman escribió:
Otra cosa a tener en cuenta es si las particiones están "aligned", esto puede dar problemas de rendimiento también.
Eso me recuerda: si es un disco nuevo con sectores de... 4K, creo que es, hay que particionar con gparted u otro que alinee en megabytes, no en sectores. Si se hace mal el disco se vuelve muy lento. Si una particion está mal alineada, esa partición es lenta.
Lo de los 4 KB además, tiene el rollo que algunos discos tienen bloques de 0.5 KB físicos y trabajan con bloques de 4 KB lógicos. Ya sabes ... compatibilidades ... <sigh> Así que también hay que tener en cuenta el tamaño de bloques del disco.
reduce el rendimiento. Aunque en tu caso sigo pensando que es un problema de acceso aleatorio e IOPS ... que también puede castigar mucho a la CPU si los ficheors son muy pequeños.
He hecho unas pruebas tontas estos dias. Me he puesto a escribir ficheros de 100 bytes en un directorio de distintos tipos de sistemas de ficheros. XFS se porta bien, pero el reiserfs aguanta millones de esos ficheros, muchísimo más que cualquier otro. El btrfs peta. Literalmente, puedes tirar abajo el kernel y la partición. Como usuario, sin ser root.
Vamos que el btrfs ni tocarlo ;)
Otra cosa, XFS se desarrolló para máquinas con mucha RAM, y muy buen sistema de IO y CPU. Si esl sistema está limitado (sobre todo en RAM), te va dar problemas de rendimiento. XFS trabaja todo lo que puede en RAM, IOW, si le dices que borre 1000 ficheros, no empieza a borrar en el momento que encuentra el primer fichero, analiza todo (en RAM) y luego borra.
Ah... curioso. Eso explica algunas cosas.
Esto se nota especialmente cuando se comprueba el disco después de algún fallo: te drena la RAM y empieza a tirar de swap como no tengas un buen montón de RAM. En las listas de XFS se ve bastante esto de usuarios que no conocen XFS. HTH Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2013-10-27 a las 22:20 +0100, Rafa Griman escribió:
Se me olvidaba ...
:-)
2013/10/26 Carlos E. R. <robin.listas@telefonica.net>:
Eso me recuerda: si es un disco nuevo con sectores de... 4K, creo que es, hay que particionar con gparted u otro que alinee en megabytes, no en sectores. Si se hace mal el disco se vuelve muy lento. Si una particion está mal alineada, esa partición es lenta.
Lo de los 4 KB además, tiene el rollo que algunos discos tienen bloques de 0.5 KB físicos y trabajan con bloques de 4 KB lógicos. Ya sabes ... compatibilidades ... <sigh> Así que también hay que tener en cuenta el tamaño de bloques del disco.
Sí, es un lio.
He hecho unas pruebas tontas estos dias. Me he puesto a escribir ficheros de 100 bytes en un directorio de distintos tipos de sistemas de ficheros. XFS se porta bien, pero el reiserfs aguanta millones de esos ficheros, muchísimo más que cualquier otro. El btrfs peta. Literalmente, puedes tirar abajo el kernel y la partición. Como usuario, sin ser root.
Vamos que el btrfs ni tocarlo ;)
Al menos si les haces burradas como las mias, no :-) La burrada en cuestión es llenar el disco con millones de ficheros, vamos... pero los otros sistemas de ficheros simplemente dan error. El btrfs puede romperse y a veces tirar abajo el sistema.
Otra cosa, XFS se desarrolló para máquinas con mucha RAM, y muy buen sistema de IO y CPU. Si esl sistema está limitado (sobre todo en RAM), te va dar problemas de rendimiento. XFS trabaja todo lo que puede en RAM, IOW, si le dices que borre 1000 ficheros, no empieza a borrar en el momento que encuentra el primer fichero, analiza todo (en RAM) y luego borra.
Ah... curioso. Eso explica algunas cosas.
Esto se nota especialmente cuando se comprueba el disco después de algún fallo: te drena la RAM y empieza a tirar de swap como no tengas un buen montón de RAM. En las listas de XFS se ve bastante esto de usuarios que no conocen XFS.
Claro, y entonces será lento. - -- Saludos Carlos E. R. (desde 12.3 x86_64 "Dartmouth" en Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJtiV4ACgkQtTMYHG2NR9Vj2wCgiTlvD3RIgumsm0DqgTUfExkk Rq4An1Y1zYoE1TCnne8dhWYx4kJv49n6 =Mv5U -----END PGP SIGNATURE-----
El 26/10/13 22:49, Rafa Griman escribió:
Hola :)
2013/10/23 admin-listas <admin-listas@satel-sa.com>:
El 25/10/2013 22:22, Rafa Griman escribió:
Hola :)
2013/10/25 Francisco F. <admin-listas@satel-sa.com>
Ver 3.6.19
4 discos en RAID 5
¿Tipos de disco?
¿RAID por SW o por HW?
Si es por HW, ¿qué controladora HW?
4 directorios y en samba 4 comparticiones para montar 4 unidades de red todas tiene la misma configuracion de samba
¿Tamaño de los ficheros?
Jajajaj, Tan quisquilloso como siempre con los detalles :)
cualquier tamaño
No me lo creo ;) ¿Tienes ficheros de 1 byte _y_ ficheros de hasta 2 PB? ;) Vamos a ser algo más específicos, si consideras ficheros grandes a los de 5 MBytes o mayor ...
¿Número de ficheros?
de 1 a 1000, los que quieras
No da o mismo. Si tienes un share con 1 fichero y otro share con 1000 ficheros ... el segundo va a sufrir mucho aún con un simple ls.
Deberías intentar equilibrar shares.
¿Sistema de ficheros?
XFS
Si usas XFS y tienes problemas de metadatos (que es lo que parece), puedes solucionarlo poniendo un disco adicional (bueno, 2 discos en RAID 1) y poner el journal en ese nuevo RAID 1. Esto no es la solución perfecta ya que tendrías que hacer más cosas, pero algo aliviaría.
Otra cosa, por norma general, XFS te detecta el RAID (stripe unit y stripe width), aunque hay veces que no. Lo ideal es que sea igual en ambos casos (RAID y XFS).
Otra cosa a tener en cuenta es si las particiones están "aligned", esto puede dar problemas de rendimiento también.
¿Tipo de datos (BBDD o no)?
Normales, dic, xls, jpg, dwg, vamos cualquier fichero
Define "normales" ;)
Volvemos a lo de antes: ¿tamaño de los ficheros y acceso/comportamiento?
¿Número de usuarios por share?
ilimitado
no somos muchos
Si no sois muchos ... no es ilimitado ;)
Define muchos ... el hardware puede tener otra definición de "no muchos".
¿Configuración de Samba?
¿Usas jumbo frames?
No, lo tengo desactivado en todos lados Si no lo tienes bien pulido da mas problemas que resuelve
Por eso lo preguntaba.
¿Cuántas tarjetas de red?
1
¿Comparten las t. de red bus PCI con otro dispositivo (tarjeta RAID)?
No
¿CPU y RAM?
2 xeon dual core
4gb sobran casi todos
Si sobran casi todos, el Linux no cachea ... luego estás haciendo acceso aleatorio a disco, esto castiga mucho los discos: tenías que haber elegido otro tipo de RAID (por ejemplo, RAID 10 ... ojo, no digo RAID 0+1, digo RAID 10).
¿Qué frecuencia? Dices que no tienes Jumbo frames luego se está produciendo muchos context switching: esto castiga mucho a la CPU y reduce el rendimiento. Aunque en tu caso sigo pensando que es un problema de acceso aleatorio e IOPS ... que también puede castigar mucho a la CPU si los ficheors son muy pequeños.
¿El sistema operativo está en ese mismo RAID 5?
No
Menos mal ;)
¿Qué otras aplicaciones/servicios tienes corriendo (Web, BBDD, correo, ...?
Da igual, si las apago sigue haciendo lo mismo
Eso que nos quitamos de encima :)
Ahora lo curioso : 3 comparticiones la velocidad con windows es normal
la 4 se esta muriendo, te puedes morir antes de que acabe de borrar o grabar algo. La lectura funciona bien.
Borrar es un proceso lento de metadatos, implica bastante IOPs. Si encima tienes muchos ficheros ... peor.
Si, pero porque solo con una comparticion de las 4 que tiene y que usan el mismo disco
Pero ese share puede que tenga más metadatos que la otra (más ficheros). Según dices antes, de los 4 GB te sobran casi todos: no cachea, haces mucho IO y muy aleatorio. No hay "read ahead", no hay cacheo, no hay buffering.
Otra cosa, XFS se desarrolló para máquinas con mucha RAM, y muy buen sistema de IO y CPU. Si esl sistema está limitado (sobre todo en RAM), te va dar problemas de rendimiento. XFS trabaja todo lo que puede en RAM, IOW, si le dices que borre 1000 ficheros, no empieza a borrar en el momento que encuentra el primer fichero, analiza todo (en RAM) y luego borra.
Si en los otros shares esto no ocurre ... es porque tienen menos ficheros. No es lo mismo para XFS borrar un directorio con 1 fichero que uno con 1000 ficheros.
A la hora de guardar un dato, el RAID 5 tiene que hacer un R/M/W (read/modify/write). Es decir, leer el bloque, modificar la paridad y escribirlo. 3 operaciones de I/O ... muy costoso.
En un RAID (3, 4, 5 ó 6), la lectura es generalmente el doble que la escritura.
El raid va bien con las otras comparticiones y en nfs
¿Mezclas NFS y SMB? ¿Con los mismos datos? Me refiero a que si un mismo fichero (directorio o no) los compartes tanto con NFS como con SMB. NO lo hagas.
Solo es para pruebas, el NFS solo lo tengo yo. En este caso el NFS iba bien asi que el samba tiene algo a descubrir. De todas formas se supone que el kernel oplooks sirve para algo (aunque parece que falla bastante)
Otra cosa, ¿cuándo NFS tienes corriendo? Teóricamente cuantos más tengas corriendo, mejor funciona ... pero más recursos consume por lo que llega un momento que se estanca.
No me vale comparar NFS con CIFS sin conocer las configuraciones. No me vale comparar 2 shares si no sé el tipo y número de ficheros que contienen. Es como decir coche A es mejor que el B ... y resulta que no sabes ni cuál es el A ni cuál es el B ni en qué condiciones se han comparado.
Te recomiendo que monitorices CPU, RAM y IO al igual que el número de ficheros de cada share.
Si alguno tiene alguna idea la pase antes de que le pegue fuego :)
Primero deberías probar cada disco (hdparm), luego pruebas el RAID con el sistema de ficheros (bonnie, ...) y luego pruebas la red (iperf).
Necesitaríamos más datos. Pero MHO es que tienes 3 opciones: - tienes diferentes tipos de acceso y hace que "compitan" por los recursos. - el RAID 5 no es la configuración ideal para el tipo de acceso de la aplicación o usuario que accede al share problemático
Si pero no se puede hacer otra cosa (la pasta manda) Y seguridad/maxima capacidad al mismo precio.
Esta reprobado que va bien todo eso.
¿El qué va bien? Y ¿cómo lo has comprobado y demostrado? Lo pregunto porque no he visto datos/resultados de monitorización.
Pues en escritura directa en el servidor entre directorios Por ftp, por ssh, por NFS, todos esos protocolos van bien.
Si lo que dices de la RAM es cierto, demuestra lo contrario: el RAID utilizado es el incorrecto. A menos que tengas otros problemas que impidan que el Linux llene la RAM (caching).
si que lo hace
¿Has monitorizado el sistema (RAM, IOPS, CPU)? Te podría ayudar a encontrar el problema ;)
Si, la CPU se pone al 100%, pero solo con samba La RAM consume lo normal
- las dos opciones anteriores son ciertas ;)
HTH
Rafa
En fin que me suena a algun dato de "cache" del samba pero no consigo encontrar solucion.
No nos has mostrado la configuración de Samba. Si es algo "compleja", mi consejo es quitar todo lo que "mejora el rendimiento" porque muchas veces depende de parámetros del kernel, el driver de red, ...
Disco RAID5 montado en /mnt/datos dentro 4 directorios A,B,C,D permisos del directorio creado root/grupo 770 todos tiene esta configuracion de samba, cambiando los nombres y ruta correspondiente [DiscoD] force directory mode = 0770 force group = grupodos # recycle:keeptree = Yes # hide dot files = yes # veto files = /.*/*.mp3/*.avi/*.{*}/ # recycle:touch = Yes # vfs objects = recycle volume = D wide links = yes path = /mnt/datos/D # hide files = /.*/ force create mode = 0770 comment = Disco L dpto D valid users = @grupodos,@grupouno create mode = 0770 # recycle:repository = /mnt/datos/A/Papelera/%U # recycle:versions = Yes directory mode = 0770 En los demas la papelera esta activada. Y el unico que va mal es la comparticion D, pero solo por SAMBA Y asi seguimos Saludos -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2013/10/28 Francisco F. <admin-listas@satel-sa.com>:
El 26/10/13 22:49, Rafa Griman escribió:
[...]
¿CPU y RAM?
2 xeon dual core
4gb sobran casi todos
[...]
¿Mezclas NFS y SMB? ¿Con los mismos datos? Me refiero a que si un mismo fichero (directorio o no) los compartes tanto con NFS como con SMB. NO lo hagas.
Solo es para pruebas, el NFS solo lo tengo yo. En este caso el NFS iba bien asi que el samba tiene algo a descubrir.
Siempre y cuando tengas las mismas aplicaciones entrando por NFS y entrando por Samba y hagas las mismas pruebas con los mismos PCs, los mismos usuarios, ... Por lo que dices de "el NFS solo lo tengo yo" ... me da que no ;)
De todas formas se supone que el kernel oplooks sirve para algo (aunque parece que falla bastante)
[...]
- el RAID 5 no es la configuración ideal para el tipo de acceso de la aplicación o usuario que accede al share problemático
Si pero no se puede hacer otra cosa (la pasta manda) Y seguridad/maxima capacidad al mismo precio.
Estoy de acuerdo, pero no puedes esperar tener un Rolls/Ferrari/... por el precio de un Ford Fiesta. Es a lo que voy. Si tienes montado un RAID 5, tienes que esperar resultados de un RAID 5.
Esta reprobado que va bien todo eso.
¿El qué va bien? Y ¿cómo lo has comprobado y demostrado? Lo pregunto porque no he visto datos/resultados de monitorización.
Pues en escritura directa en el servidor entre directorios Por ftp, por ssh, por NFS, todos esos protocolos van bien.
¿Esos protocolos van bien desde los mismos PCs que el Samba? Lo pregunto porque dices que el NFS lo usas tú para pruebas y te funciona bien, pero no dices si es desde los mismos PCs que tienen problemas con Samba o desde otro.
Si lo que dices de la RAM es cierto, demuestra lo contrario: el RAID utilizado es el incorrecto. A menos que tengas otros problemas que impidan que el Linux llene la RAM (caching).
si que lo hace
Entonces no entiendo por qué dices más arriba cuando te pregunto sobre la RAM: "4gb sobran casi todos" Si está cacheando, no sobrarían. No entiendo tu respuesta.
¿Has monitorizado el sistema (RAM, IOPS, CPU)? Te podría ayudar a encontrar el problema ;)
Si, la CPU se pone al 100%, pero solo con samba La RAM consume lo normal
Preguntas: 1.- Si la CPU se pone al 100%, ¿con qué procesos? ¿Sólo con el demonio smb/nmb? 2.- ¿Has medido IOPs mientras la CPU está al 100%? 3.- ¿Qué es normal? Para mis clientes normal es consumir 64 GB de RAM. ¿Es eso normal para tu caso? 4.- ¿Qué ocurre en los Windows? ¿La CPU se pone al 100%? ¿Cuándo? ¿Con qué aplicación?
En fin que me suena a algun dato de "cache" del samba pero no consigo encontrar solucion.
Monitoriza RAM, CPU e I/O al mismo tiempo y localiza cuándo y quién hace que la CPU se dispare. No sabemos si es siempre, si es sólo cuando el usuario PEPE conecta, si es sólo cuando la aplicación ABC accede por Samba, si pasa con 1 PC o desde el momento que se conectan X PCs, si es al acceder a un directorio determinado, ... Yo sigo convencido que es por el número, tamaño, tipo de fichero o tipo de acceso a disco. Si fuera la RAM ... afectaría a todos los shares por igual ... a menos que la configuración de dicho share sea diferente a las demás.
No nos has mostrado la configuración de Samba. Si es algo "compleja", mi consejo es quitar todo lo que "mejora el rendimiento" porque muchas veces depende de parámetros del kernel, el driver de red, ...
Disco RAID5 montado en /mnt/datos
dentro 4 directorios A,B,C,D
permisos del directorio creado root/grupo 770
todos tiene esta configuracion de samba, cambiando los nombres y ruta correspondiente
[DiscoD] force directory mode = 0770 force group = grupodos # recycle:keeptree = Yes # hide dot files = yes # veto files = /.*/*.mp3/*.avi/*.{*}/ # recycle:touch = Yes # vfs objects = recycle volume = D wide links = yes path = /mnt/datos/D # hide files = /.*/ force create mode = 0770 comment = Disco L dpto D valid users = @grupodos,@grupouno create mode = 0770 # recycle:repository = /mnt/datos/A/Papelera/%U # recycle:versions = Yes directory mode = 0770
En los demas la papelera esta activada.
Y el unico que va mal es la comparticion D, pero solo por SAMBA
¿Y la [global]? Si todos los share tienen exactamente la misma configuración (salvo la papelera), sigo pensando que es un problema de disco (# de ficheros, tipo, tipo de acceso, ...). Si sólo afecta a D y todos los shares tienen la misma configuración y todo es igual ... lo que cambia es lo que te digo de los ficheros, acceso a disco, ... Excepto la papelera ... activa la papelera a ver qué pasa. ¿Tienes algún tipo de aplicación que hace algo específico en D cuando se accede? ¿Antivirus, deduplicación, backup, comprimir, descomprimir, archivar, ...? HTH Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 25/10/13 14:54, Francisco F. escribió:
Ver 3.6.19
4 discos en RAID 5
4 directorios y en samba 4 comparticiones para montar 4 unidades de red todas tiene la misma configuracion de samba
Ahora lo curioso : 3 comparticiones la velocidad con windows es normal
la 4 se esta muriendo, te puedes morir antes de que acabe de borrar o grabar algo. La lectura funciona bien.
Si alguno tiene alguna idea la pase antes de que le pegue fuego :)
Saludos
Es el fichero locking.tdb http://edoceo.com/howto/samba Graciosa la semejanza del Reboot En mi caso tenia 18MB pero con un tdbdump locking.tdb >tdb.txt apenas salian 300kb, vaciandolo tampoco se soluccionaba mucho tdbtool >>>> open locking.tdb >>>>> erase Asi que parada del servicio, borrado a mano y reinicio del servicio. Se vuelve a crear con poco mas de 6MB, cansado lo borro a pelo y entonces va todo de cine, pero no se crea otra vez si no reinicias el servicio, lo hago y hasta el momento aguanta. Ahora el fichero ocupa 4,5MB y el volcado 250kb. Sera cuestion de vigilarlo enlace para ver los ficheros tdb que se pueden o deben borrar http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/tdb.html Lo que ya no se la obsesion que tenia por una sola comparticion. Gracias a Rafa :) por dejarnos a la altura del betun e intentar desaznarnos. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (4)
-
admin-listas -
Carlos E. R. -
Francisco F.
-
Rafa Griman