[opensuse-es] Un proceso de samba satura el procesador en openSUSE 11.1
Hola tod@s, A donde un cliente instalamos un servidor OpenSuse 11.1 con Samba, para que comparten los archivos de manera centralizada, y no guardan nada en sus PC. Parte de la red esta inhalambrica. En ciertos momento, el proceso smbd ocupa 100% del CPU, y deja el servidor suuuuuuper lento, o indisponible. Lo raro es que se hace imposible matar al proceso que ocupa el CPU. Ni un kill -9 del proceso lo mata :-((( Solo cortando la luz permite reiniciar el servidor. Cambiamos la versión de de la versión 3.3.0 a la versión 3.2.6, esperando que resuelva el problema. Nada, igual en algun momento (varios minutos o horas) regresa el problema. Sospechamos que algun(os?) usuario cierra mal su conneccion (o pierde un intante la conexion wifi (?), y eso vuelve el Samba loco. En Internet, no encontré respuesta satisfactoria a mi problema. Alguien ya tuve este problema y lo pudo resolver? smb.conf [global] workgroup = MEDLAB server string = Servidor de archivos de Medlab map to guest = Bad User null passwords = Yes guest account = samba printcap name = cups ldap ssl = no create mask = 0777 force create mode = 0777 force security mode = 0777 directory mask = 0777 force directory mode = 0777 force directory security mode = 0777 cups options = raw [users] comment = All users path = /shared read only = No inherit acls = Yes veto files = /aquota.user/groups/shares/ [admon] comment = Administracion path = /shared/admon read only = No inherit acls = Yes veto files = /aquota.user/groups/shares/ [clientes] comment = Clientes path = /shared/clientes read only = No inherit acls = Yes veto files = /aquota.user/groups/shares/ [gerencia] comment = Gerencia path = /shared/gerencia read only = No inherit acls = Yes veto files = /aquota.user/groups/shares/ [medicos] comment = Medicos path = /shared/medicos/ inherit acls = yes veto files = /aquota.user/groups/shares/ guest ok = yes read only = no [compartido] comment = All groups path = /shared/compartido/ username = samba read only = No acl check permissions = No force unknown acl user = Yes guest ok = Yes hosts allow = 192.168.1. =========================================================== Abajo un extracto de smbd.log para el dia de hoy. Espero que encontraras la razon. El proceso que ocupa 100% es el 11878, iniciado segun el log por el IP 192.168.1.67 (los IP son fijos) a las 8h51, y este IP cerro las conexiones a las 11h57, pero son las 12h35 y el pid 11878 ocupa 100% del CPU y no logro matarlo ;-((( Talvez hay algo otro que no he visto... Algo raro: el pid 11878 esta (ahora) a nombre de root y no de admon... Tambien el TIME dice 37:24 que es igual al tiempo entre las 11h57 y las 12h35. Algo sale mal al momento de cerrar la conexion y parar el proceso... TOP: top - 12:35:00 up 19:40, 1 user, load average: 3.01, 2.92, 2.33 Tasks: 132 total, 4 running, 128 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 25.0%sy, 0.0%ni, 74.5%id, 0.3%wa, 0.0%hi, 0.2%si, 0.0%st Mem: 2048884k total, 1996896k used, 51988k free, 98664k buffers Swap: 2104504k total, 28k used, 2104476k free, 1506752k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 11878 root 20 0 16984 5188 3932 R 100 0.3 37:24.13 smbd 14763 root 20 0 2432 1132 848 R 1 0.1 0:00.04 top 1 root 20 0 1008 380 332 S 0 0.0 0:02.00 init 2 root 15 -5 0 0 0 S 0 0.0 0:00.00 kthreadd 3 root RT -5 0 0 0 S 0 0.0 0:00.00 migration/0 4 root 15 -5 0 0 0 S 0 0.0 0:00.84 ksoftirqd/0 5 root RT -5 0 0 0 S 0 0.0 0:00.00 migration/1 6 root 15 -5 0 0 0 S 0 0.0 0:00.50 ksoftirqd/1 7 root RT -5 0 0 0 S 0 0.0 0:00.00 migration/2 8 root 15 -5 0 0 0 S 0 0.0 0:00.24 ksoftirqd/2 9 root RT -5 0 0 0 S 0 0.0 0:00.00 migration/3 10 root 15 -5 0 0 0 S 0 0.0 0:00.28 ksoftirqd/3 11 root 15 -5 0 0 0 S 0 0.0 0:00.82 events/0 log.smbd: [2009/02/14 03:45:15, 0] smbd/server.c:main(1208) smbd version 3.2.6-0.3.1-2042-SUSE-CODE11 started. Copyright Andrew Tridgell and the Samba Team 1992-2008 [2009/02/14 07:25:36, 1] smbd/service.c:make_connection_snum(1194) nadia (::ffff:192.168.1.104) connect to service admon initially as user admon (uid=1002, gid=100) (pid 11622) [2009/02/14 07:34:17, 1] smbd/service.c:make_connection_snum(1194) lenovo_medicos (::ffff:192.168.1.80) connect to service medicos initially as user medicos (uid=1004, gid=100) (pid 11651) [2009/02/14 07:34:17, 1] smbd/service.c:make_connection_snum(1194) lenovo_medicos (::ffff:192.168.1.80) connect to service compartido initially as user medicos (uid=1004, gid=100) (pid 11651) [2009/02/14 07:42:03, 1] smbd/service.c:make_connection_snum(1194) recepcion (::ffff:192.168.1.112) connect to service compartido initially as user admon (uid=1002, gid=100) (pid 11661) [2009/02/14 07:49:43, 1] smbd/service.c:make_connection_snum(1194) contabilidad (::ffff:192.168.1.68) connect to service admon initially as user admon (uid=1002, gid=100) (pid 11694) [2009/02/14 07:49:43, 1] smbd/service.c:make_connection_snum(1194) contabilidad (::ffff:192.168.1.68) connect to service compartido initially as user admon (uid=1002, gid=100) (pid 11694) [2009/02/14 07:49:44, 0] lib/util_sock.c:get_peer_addr_internal(1607) getpeername failed. Error was El otro extremo de la conexión no está conectado [2009/02/14 07:49:44, 0] lib/util_sock.c:read_socket_with_timeout(939) [2009/02/14 07:49:44, 0] lib/util_sock.c:get_peer_addr_internal(1607) getpeername failed. Error was El otro extremo de la conexión no está conectado read_socket_with_timeout: client 0.0.0.0 read error = Conexión reinicializada por la máquina remota. [2009/02/14 07:53:58, 1] smbd/service.c:make_connection_snum(1194) direccion_medic (::ffff:192.168.1.70) connect to service medicos initially as user medicos (uid=1004, gid=100) (pid 11698) [2009/02/14 07:53:58, 1] smbd/service.c:make_connection_snum(1194) direccion_medic (::ffff:192.168.1.70) connect to service compartido initially as user medicos (uid=1004, gid=100) (pid 11698) [2009/02/14 07:54:06, 1] smbd/service.c:make_connection_snum(1194) server_medlab (::ffff:192.168.1.71) connect to service clientes initially as user clientes (uid=1006, gid=100) (pid 11700) [2009/02/14 07:54:06, 1] smbd/service.c:make_connection_snum(1194) server_medlab (::ffff:192.168.1.71) connect to service users initially as user clientes (uid=1006, gid=100) (pid 11700) [2009/02/14 08:05:12, 1] smbd/service.c:make_connection_snum(1194) emma (::ffff:192.168.1.162) connect to service medicos initially as user medicos (uid=1004, gid=100) (pid 11739) [2009/02/14 08:05:12, 1] smbd/service.c:make_connection_snum(1194) emma (::ffff:192.168.1.162) connect to service compartido initially as user medicos (uid=1004, gid=100) (pid 11739) [2009/02/14 08:05:15, 0] lib/util_sock.c:get_peer_addr_internal(1607) getpeername failed. Error was El otro extremo de la conexión no está conectado [2009/02/14 08:05:15, 0] lib/util_sock.c:read_socket_with_timeout(939) [2009/02/14 08:05:15, 0] lib/util_sock.c:get_peer_addr_internal(1607) getpeername failed. Error was El otro extremo de la conexión no está conectado read_socket_with_timeout: client 0.0.0.0 read error = Conexión reinicializada por la máquina remota. [2009/02/14 08:09:42, 0] lib/util_sock.c:read_socket_with_timeout(939) [2009/02/14 08:09:42, 0] lib/util_sock.c:get_peer_addr_internal(1607) getpeername failed. Error was El otro extremo de la conexión no está conectado read_socket_with_timeout: client 0.0.0.0 read error = Conexión reinicializada por la máquina remota. [2009/02/14 08:09:42, 1] smbd/service.c:close_cnum(1405) contabilidad (::ffff:192.168.1.68) closed connection to service compartido [2009/02/14 08:09:42, 1] smbd/service.c:close_cnum(1405) contabilidad (::ffff:192.168.1.68) closed connection to service admon [2009/02/14 08:15:07, 1] smbd/service.c:make_connection_snum(1194) contabilidad (::ffff:192.168.1.68) connect to service admon initially as user admon (uid=1002, gid=100) (pid 11772) [2009/02/14 08:20:06, 0] lib/util_sock.c:read_socket_with_timeout(939) [2009/02/14 08:20:06, 0] lib/util_sock.c:get_peer_addr_internal(1607) getpeername failed. Error was El otro extremo de la conexión no está conectado read_socket_with_timeout: client 0.0.0.0 read error = Conexión reinicializada por la máquina remota. [2009/02/14 08:20:06, 1] smbd/service.c:close_cnum(1405) contabilidad (::ffff:192.168.1.68) closed connection to service admon [2009/02/14 08:22:57, 1] smbd/service.c:make_connection_snum(1194) medlab (::ffff:192.168.1.67) connect to service admon initially as user admon (uid=1002, gid=100) (pid 11787) [2009/02/14 08:23:04, 1] smbd/service.c:make_connection_snum(1194) medlab (::ffff:192.168.1.67) connect to service compartido initially as user admon (uid=1002, gid=100) (pid 11787) [2009/02/14 08:24:08, 1] smbd/service.c:make_connection_snum(1194) contabilidad (::ffff:192.168.1.68) connect to service admon initially as user admon (uid=1002, gid=100) (pid 11791) [2009/02/14 08:24:11, 0] lib/util_sock.c:read_socket_with_timeout(939) [2009/02/14 08:24:11, 0] lib/util_sock.c:get_peer_addr_internal(1607) getpeername failed. Error was El otro extremo de la conexión no está conectado read_socket_with_timeout: client 0.0.0.0 read error = Conexión reinicializada por la máquina remota. [2009/02/14 08:30:35, 0] lib/util_sock.c:read_socket_with_timeout(939) [2009/02/14 08:30:35, 0] lib/util_sock.c:get_peer_addr_internal(1607) getpeername failed. Error was El otro extremo de la conexión no está conectado read_socket_with_timeout: client 0.0.0.0 read error = Conexión reinicializada por la máquina remota. [2009/02/14 08:30:35, 1] smbd/service.c:close_cnum(1405) contabilidad (::ffff:192.168.1.68) closed connection to service admon [2009/02/14 08:32:15, 1] smbd/service.c:make_connection_snum(1194) contabilidad (::ffff:192.168.1.68) connect to service admon initially as user admon (uid=1002, gid=100) (pid 11819) [2009/02/14 08:38:48, 1] smbd/service.c:close_cnum(1405) medlab (::ffff:192.168.1.67) closed connection to service admon [2009/02/14 08:38:48, 1] smbd/service.c:close_cnum(1405) medlab (::ffff:192.168.1.67) closed connection to service compartido [2009/02/14 08:44:47, 0] lib/util_sock.c:get_peer_addr_internal(1607) getpeername failed. Error was El otro extremo de la conexión no está conectado [2009/02/14 08:44:47, 0] lib/util_sock.c:read_socket_with_timeout(939) [2009/02/14 08:44:47, 0] lib/util_sock.c:get_peer_addr_internal(1607) getpeername failed. Error was El otro extremo de la conexión no está conectado read_socket_with_timeout: client 0.0.0.0 read error = Conexión reinicializada por la máquina remota. [2009/02/14 08:46:28, 1] smbd/service.c:make_connection_snum(1194) medlab (::ffff:192.168.1.67) connect to service admon initially as user admon (uid=1002, gid=100) (pid 11868) [2009/02/14 08:46:28, 1] smbd/service.c:make_connection_snum(1194) medlab (::ffff:192.168.1.67) connect to service compartido initially as user admon (uid=1002, gid=100) (pid 11868) [2009/02/14 08:47:33, 0] lib/util_sock.c:read_socket_with_timeout(939) [2009/02/14 08:47:33, 0] lib/util_sock.c:get_peer_addr_internal(1607) getpeername failed. Error was El otro extremo de la conexión no está conectado read_socket_with_timeout: client 0.0.0.0 read error = Conexión reinicializada por la máquina remota. [2009/02/14 08:47:33, 1] smbd/service.c:close_cnum(1405) contabilidad (::ffff:192.168.1.68) closed connection to service admon [2009/02/14 08:47:46, 0] lib/util_sock.c:read_socket_with_timeout(939) [2009/02/14 08:47:46, 0] lib/util_sock.c:get_peer_addr_internal(1607) getpeername failed. Error was El otro extremo de la conexión no está conectado read_socket_with_timeout: client 0.0.0.0 read error = Conexión reinicializada por la máquina remota. [2009/02/14 08:47:46, 1] smbd/service.c:make_connection_snum(1194) contabilidad (::ffff:192.168.1.68) connect to service admon initially as user admon (uid=1002, gid=100) (pid 11873) [2009/02/14 08:50:18, 1] smbd/service.c:close_cnum(1405) medlab (::ffff:192.168.1.67) closed connection to service admon [2009/02/14 08:50:18, 1] smbd/service.c:close_cnum(1405) medlab (::ffff:192.168.1.67) closed connection to service compartido **************************** [2009/02/14 08:51:20, 1] smbd/service.c:make_connection_snum(1194) medlab (::ffff:192.168.1.67) connect to service admon initially as user admon (uid=1002, gid=100) (pid 11878) [2009/02/14 08:51:20, 1] smbd/service.c:make_connection_snum(1194) medlab (::ffff:192.168.1.67) connect to service compartido initially as user admon (uid=1002, gid=100) (pid 11878) **************************** [2009/02/14 09:37:46, 0] lib/util_sock.c:read_socket_with_timeout(939) [2009/02/14 09:37:46, 0] lib/util_sock.c:get_peer_addr_internal(1607) getpeername failed. Error was El otro extremo de la conexión no está conectado read_socket_with_timeout: client 0.0.0.0 read error = Conexión reinicializada por la máquina remota. [2009/02/14 09:37:46, 1] smbd/service.c:close_cnum(1405) contabilidad (::ffff:192.168.1.68) closed connection to service admon [2009/02/14 10:06:23, 1] smbd/service.c:make_connection_snum(1194) contabilidad (::ffff:192.168.1.68) connect to service admon initially as user admon (uid=1002, gid=100) (pid 14293) [2009/02/14 10:06:26, 0] lib/util_sock.c:get_peer_addr_internal(1607) getpeername failed. Error was El otro extremo de la conexión no está conectado [2009/02/14 10:06:26, 0] lib/util_sock.c:read_socket_with_timeout(939) [2009/02/14 10:06:26, 0] lib/util_sock.c:get_peer_addr_internal(1607) getpeername failed. Error was El otro extremo de la conexión no está conectado read_socket_with_timeout: client 0.0.0.0 read error = Conexión reinicializada por la máquina remota. [2009/02/14 11:47:29, 1] smbd/service.c:close_cnum(1405) nadia (::ffff:192.168.1.104) closed connection to service admon [2009/02/14 11:53:07, 1] smbd/notify_inotify.c:watch_destructor(351) inotify_rm_watch returned Argumento inválido [2009/02/14 11:53:11, 1] smbd/notify_inotify.c:watch_destructor(351) inotify_rm_watch returned Argumento inválido [2009/02/14 11:53:24, 1] smbd/notify_inotify.c:watch_destructor(351) inotify_rm_watch returned Argumento inválido [2009/02/14 11:53:27, 1] smbd/notify_inotify.c:watch_destructor(351) inotify_rm_watch returned Argumento inválido [2009/02/14 11:55:58, 1] smbd/service.c:close_cnum(1405) recepcion (::ffff:192.168.1.112) closed connection to service compartido [2009/02/14 11:57:54, 1] smbd/notify_inotify.c:watch_destructor(351) inotify_rm_watch returned Argumento inválido ******************** [2009/02/14 11:57:58, 1] smbd/service.c:close_cnum(1405) medlab (::ffff:192.168.1.67) closed connection to service compartido [2009/02/14 11:57:58, 1] smbd/service.c:close_cnum(1405) medlab (::ffff:192.168.1.67) closed connection to service admon ******************** [2009/02/14 12:01:14, 1] smbd/service.c:close_cnum(1405) lenovo_medicos (::ffff:192.168.1.80) closed connection to service medicos [2009/02/14 12:01:14, 1] smbd/service.c:close_cnum(1405) lenovo_medicos (::ffff:192.168.1.80) closed connection to service compartido [2009/02/14 12:03:56, 1] smbd/service.c:close_cnum(1405) emma (::ffff:192.168.1.162) closed connection to service medicos [2009/02/14 12:03:56, 1] smbd/service.c:close_cnum(1405) emma (::ffff:192.168.1.162) closed connection to service compartido [2009/02/14 12:05:15, 1] smbd/service.c:make_connection_snum(1194) ar (::ffff:192.168.1.54) connect to service medicos initially as user gerencia (uid=1003, gid=100) (pid 14639) [2009/02/14 12:05:15, 1] smbd/service.c:make_connection_snum(1194) ar (::ffff:192.168.1.54) connect to service admon initially as user gerencia (uid=1003, gid=100) (pid 14639) [2009/02/14 12:05:15, 1] smbd/service.c:make_connection_snum(1194) ar (::ffff:192.168.1.54) connect to service gerencia initially as user gerencia (uid=1003, gid=100) (pid 14639) [2009/02/14 12:05:15, 1] smbd/service.c:make_connection_snum(1194) ar (::ffff:192.168.1.54) connect to service clientes initially as user gerencia (uid=1003, gid=100) (pid 14639) [2009/02/14 12:05:15, 1] smbd/service.c:make_connection_snum(1194) ar (::ffff:192.168.1.54) connect to service compartido initially as user gerencia (uid=1003, gid=100) (pid 14639) [2009/02/14 12:05:18, 0] lib/util_sock.c:read_socket_with_timeout(939) [2009/02/14 12:05:18, 0] lib/util_sock.c:get_peer_addr_internal(1607) getpeername failed. Error was El otro extremo de la conexión no está conectado read_socket_with_timeout: client 0.0.0.0 read error = Conexión reinicializada por la máquina remota. [2009/02/14 12:08:26, 1] smbd/service.c:close_cnum(1405) server_medlab (::ffff:192.168.1.71) closed connection to service clientes [2009/02/14 12:08:26, 1] smbd/service.c:close_cnum(1405) server_medlab (::ffff:192.168.1.71) closed connection to service users -- Ing. Alejandro Rodriguez || @LeX Usuario Linux # 379802 openSUSE 11.1 -- 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 2009-02-14 a las 13:46 -0600, Alex Rodriguez escribió:
Lo raro es que se hace imposible matar al proceso que ocupa el CPU. Ni un kill -9 del proceso lo mata :-(((
rcsmb stop - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmXIuwACgkQtTMYHG2NR9UU+QCdFxU22PqiX0H7zq9W9dhXVPdv qc4An0WU4amGEfDDFbY1BUQ9O9MzOwiW =qSoy -----END PGP SIGNATURE-----
El día 14 de febrero de 2009 14:00, Carlos E. R.
El 2009-02-14 a las 13:46 -0600, Alex Rodriguez escribió:
Lo raro es que se hace imposible matar al proceso que ocupa el CPU. Ni un kill -9 del proceso lo mata :-(((
rcsmb stop
lo puedes detener sin problema y hasta reiniciar pero siempres tiene los procesos activos =( -- Ing. Alejandro Rodriguez || @LeX Usuario Linux # 379802 openSUSE 11.1 -- 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 2009-02-14 a las 14:41 -0600, Alex Rodriguez escribió:
El día 14 de febrero de 2009 14:00, Carlos E. R.
rcsmb stop
lo puedes detener sin problema y hasta reiniciar pero siempres tiene los procesos activos
Con "smbstatus" podrás ver si hay archivos bloqueados. Con "pidof smbd|nmbd" podrás ver los procesos y luegos los matas a todos con un kill >:-) Otra opción: reiniciar la red para matar esas conexiones inactivas / fantasmas. Saludos, -- Camaleón -- 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
Alex Rodriguez escribió:
Hola tod@s,
A donde un cliente instalamos un servidor OpenSuse 11.1 con Samba, para que comparten los archivos de manera centralizada, y no guardan nada en sus PC.
Parte de la red esta inhalambrica.
En ciertos momento, el proceso smbd ocupa 100% del CPU, y deja el servidor suuuuuuper lento, o indisponible.
Lo raro es que se hace imposible matar al proceso que ocupa el CPU. Ni un kill -9 del proceso lo mata :-(((
Solo cortando la luz permite reiniciar el servidor.
Cambiamos la versión de de la versión 3.3.0 a la versión 3.2.6, esperando que resuelva el problema. Nada, igual en algun momento (varios minutos o horas) regresa el problema.
Sospechamos que algun(os?) usuario cierra mal su conneccion (o pierde un intante la conexion wifi (?), y eso vuelve el Samba loco.
En Internet, no encontré respuesta satisfactoria a mi problema.
Alguien ya tuve este problema y lo pudo resolver?
smb.conf
[global] workgroup = MEDLAB server string = Servidor de archivos de Medlab map to guest = Bad User null passwords = Yes guest account = samba printcap name = cups ldap ssl = no create mask = 0777 force create mode = 0777 force security mode = 0777 directory mask = 0777 force directory mode = 0777 force directory security mode = 0777 cups options = raw
Cuantas tarjetas de red tiene ese servidor. Restringiria el uso de samba por interface interface= 192.168.1.1/24 127.0.0.1 o la ip que tengas asignada el 127 siempre hay que ponerlo -- 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 :) El Saturday 14 February 2009, Alex Rodriguez escribió:
Hola tod@s,
A donde un cliente instalamos un servidor OpenSuse 11.1 con Samba, para que comparten los archivos de manera centralizada, y no guardan nada en sus PC.
Vamos, que soporta mucha carga el Samba.
Parte de la red esta inhalambrica.
En ciertos momento, el proceso smbd ocupa 100% del CPU, y deja el servidor suuuuuuper lento, o indisponible.
Lo raro es que se hace imposible matar al proceso que ocupa el CPU. Ni un kill -9 del proceso lo mata :-(((
Consejo, cuando tienes un proceso que no hay manera de matarlo (-9 tampoco funciona). Lo más probable es que esté en estado D (Uninterruptible Sleep). Es decir, está haciendo I/O a disco. NO puedes matar procesos en este estado.
Solo cortando la luz permite reiniciar el servidor.
Si :(
Cambiamos la versi�n de de la versi�n 3.3.0 a la versi�n 3.2.6, esperando que resuelva el problema. Nada, igual en algun momento (varios minutos o horas) regresa el problema.
Sospechamos que algun(os?) usuario cierra mal su conneccion (o pierde un intante la conexion wifi (?), y eso vuelve el Samba loco.
Puede ser.
Abajo un extracto de smbd.log para el dia de hoy. Espero que encontraras la razon.
El proceso que ocupa 100% es el 11878, iniciado segun el log por el IP 192.168.1.67 (los IP son fijos) a las 8h51, y este IP cerro las conexiones a las 11h57, pero son las 12h35 y el pid 11878 ocupa 100% del CPU y no logro matarlo ;-(((
Talvez hay algo otro que no he visto...
Algo raro: el pid 11878 esta (ahora) a nombre de root y no de admon... Tambien el TIME dice 37:24 que es igual al tiempo entre las 11h57 y las 12h35. Algo sale mal al momento de cerrar la conexion y parar el proceso...
A ver, preguntas: ¿cuántos usuarios tienes conectados simultáneamente? ¿qué HW tiene tu servidor Samba: CPU, RAM, T. red, discos? Y su configuración: bonding, RAID, ... ¿la RAM la tienes distribuida de forma que están todos los canales utilizados? ¿qué tipo de ficheros se manejan? ¿qué tamaño de ficheros se manejan? ¿cuántos ficheros se manejan simultáneamente? ¿t. red son gigabit? En caso afirmativo, ¿usas jumbo frames? ¿Los PCs tienen Gigabit y usan jumbo frames? ¿Los switches? ¿el servidor corre otros servicios: correo, web, proxy, ...? ¿sistema de ficheros utilizado y opciones a la hora de crearlo? ¿cuántos sistemas de ficehros tienes compartidos? ¿controladoras de disco? ¿Tecnología de los discos? ¿compartes bus PCI entre dispositivos? En caso afirmativo, ¿qué dispositivos? Y ¿qué tipo de bus (PCI, PCI-X 32/64, PCIe, AGP)? Tienes que tener en cuenta una cosa: SMB crea un proceso hijo por cada PC cliente que se conecta. Samba CARGA MUCHO los servidores. Para dimensionar bien un Samba, piensa de la siguiente manera: CPU: - 1 GHz por tarjeta Gigabit Ethernet - 1 GHz para el Samba - 1 GHz para el sistema operativo - 1 GHz para el RAID (si es por software) - 1 GHz para el gestor de volúmenes (si usas alguno) RAM - 1 GB de RAM por usuario concurrente - 1 GB de RAM para el sistema operativo - 1 GB de RAM para el Samba Obviamente, son números sacados a "ojímetro". Es decir, no hay ninguna ciencia matemática que ha demostrado esto, son "best practices". Teniendo en cuenta que es un entorno médico, posiblemente estés trabajando con ficheros grandes (radiografías, posiblemente TACs, audio para grabación de exploraciones pulmonares o cardíacas, algún vídeo si se graban sesiones de algún paciente para estudiar comportamientos, ...) y pequeños (citas, ficheros de texto con historial clínico, ...). Esto mata a los discos :( HTH Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- 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
En mi opinion las redes inhalambricas causan muchas perdidas, y esto ha de ser parte del problema. Al menos con redes fisicas se ha de comportar un poco mejor, y tambien como menciona Rafa hay que ver la parte del hardware muy de cerca. -- -=> Roberto José Blandino Cisneros -=> Nicaragua, Nicaragua http://gnu-linux-opensource.blogspot.com/ http://softwarelibre.uni.edu.ni/ -- 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 2009-02-14 a las 13:46 -0600, Alex Rodriguez escribió:
A donde un cliente instalamos un servidor OpenSuse 11.1 con Samba, para que comparten los archivos de manera centralizada, y no guardan nada en sus PC.
Parte de la red esta inhalambrica.
En ciertos momento, el proceso smbd ocupa 100% del CPU, y deja el servidor suuuuuuper lento, o indisponible.
(...) FYI: Bug 475998 - smbd hangs at 100% CPU and is unkillable https://bugzilla.novell.com/show_bug.cgi?id=475998 Saludos, -- Camaleón -- 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 día 18 de febrero de 2009 1:35, Camaleón
El 2009-02-14 a las 13:46 -0600, Alex Rodriguez escribió: (...)
FYI:
Bug 475998 - smbd hangs at 100% CPU and is unkillable https://bugzilla.novell.com/show_bug.cgi?id=475998
A pues en efecto es un problema gigante :s :( -- Ing. Alejandro Rodriguez || @LeX Usuario Linux # 379802 openSUSE 11.1 -- 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 2009-02-18 a las 09:09 -0600, Alex Rodriguez escribió:
A pues en efecto es un problema gigante :s :(
Dicen que el kernel del kotd corrije el error, pero en una máquina en producción no sé si sería conveniente instalarlo (te podría generar otros problemas) o esperar a que lo actualicen por el método convencional O:-) Saludos, -- Camaleón -- 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 (6)
-
admin-listas
-
Alex Rodriguez
-
Camaleón
-
Carlos E. R.
-
Rafa Grimán
-
Roberto José Blandino Cisneros