Estimados, tengo un servidor de imagenes en Suse 10.1, al cual se suben images desde un software desarrollado en Visual Basic usando ftp. Para esto, instale vsftp, diariamente se suben aprox 20,000 imagenes, pero el proceso es demasiado lento, pues para subir 1000 archivos se tarda aproximadamente 1 hora 30 minutos, ahora mi pregunta es la siguiente, hay alguna forma de hacer que la transferencia, sea mas rapida? esto es parte del archivo /var/log/vsftpd Mon Jul 10 15:12:27 2006 [pid 4894] [bbva] FTP response: Client "10.10.10.10", "226 File receive OK." Mon Jul 10 15:12:27 2006 [pid 4894] [bbva] FTP command: Client "10.10.10.10", "TYPE I" Mon Jul 10 15:12:27 2006 [pid 4894] [bbva] FTP response: Client "10.10.10.10", "200 Switching to Binary mode." Mon Jul 10 15:12:27 2006 [pid 4894] [bbva] FTP command: Client "10.10.10.10", "PORT 10,10,10,10,6,121" Mon Jul 10 15:12:27 2006 [pid 4894] [bbva] FTP response: Client "10.10.10.10", "200 PORT command successful. Consider using PASV." Mon Jul 10 15:12:27 2006 [pid 4894] [bbva] FTP command: Client "10.10.10.10", "STOR 108875.jpg" Mon Jul 10 15:12:27 2006 [pid 4894] [bbva] FTP response: Client "10.10.10.10", "150 Ok to send data." Mon Jul 10 15:12:32 2006 [pid 4894] [bbva] OK UPLOAD: Client "10.10.10.10", "/Imagenes/Pecuza/108875.jpg", 121384 bytes, 25.54Kbyte/sec la ip 10.10.10.10 es la tarjeta DMZ de mi proxy, el proxy es squid sobre Suse 9.1. quedo en espera de sus sugerencias y comentarios. Saludos JCarlos -- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
2006/7/10, Juan Carlos Bravo Celis
Estimados, tengo un servidor de imagenes en Suse 10.1, al cual se suben images desde un software desarrollado en Visual Basic usando ftp. Para esto, instale vsftp, diariamente se suben aprox 20,000 imagenes, pero el proceso es demasiado lento, pues para subir 1000 archivos se tarda aproximadamente 1 hora 30 minutos, ahora mi pregunta es la siguiente, hay alguna forma de hacer que la transferencia, sea mas rapida?
- disminuir el tamano de las imagens con menos calidad y/o algun formato distinto !!! - cambiar las actuales tarjetas de redes por modelos mas rapidos (gigabytes) !!! - agregar una segunda tarjeta de red en el servidor y cliente y hacer una conexcion exclusiva entre ambos - comprirmir del lado del cliente y descomprimir en el lado del servidor !!! - grabar en CD y llevar el CD hasta el server. - tener paciencia y dejar copiando durante el final de semana !!!
esto es parte del archivo /var/log/vsftpd
[...]
Mon Jul 10 15:12:27 2006 [pid 4894] [bbva] FTP response: Client "10.10.10.10", "150 Ok to send data." Mon Jul 10 15:12:32 2006 [pid 4894] [bbva] OK UPLOAD: Client "10.10.10.10", "/Imagenes/Pecuza/108875.jpg", 121384 bytes, 25.54Kbyte/sec
la ip 10.10.10.10 es la tarjeta DMZ de mi proxy, el proxy es squid sobre Suse 9.1.
el trafico es de 25Kbytes/s y esto dentro de una red interna deberia de indicar algun problema con la (las) tarjetas de red o congestion en la propia red (cables/switchs) o algun limitador de ancho de banda.
quedo en espera de sus sugerencias y comentarios.
por cierto, trabajas en un banco ?? por aca tenemos uno que se llama bbva, tambien !! ;-) -- -- Victor Hugo dos Santos Linux Counter #224399 -- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
On 10/07/06, Victor Hugo dos Santos
2006/7/10, Juan Carlos Bravo Celis
: Estimados, tengo un servidor de imagenes en Suse 10.1, al cual se suben images desde un software desarrollado en Visual Basic usando ftp. Para esto, instale vsftp, diariamente se suben aprox 20,000 imagenes, pero el proceso es demasiado lento, pues para subir 1000 archivos se tarda aproximadamente 1 hora 30 minutos, ahora mi pregunta es la siguiente, hay alguna forma de hacer que la transferencia, sea mas rapida?
- disminuir el tamano de las imagens con menos calidad y/o algun formato distinto !!!
imposible, estan al minimo, se requiere que las imagenes sean en formato jpg. 150k aprox por imagen
- cambiar las actuales tarjetas de redes por modelos mas rapidos (gigabytes) !!!
las tarjetas son de 1Gbit
- agregar una segunda tarjeta de red en el servidor y cliente y hacer una conexcion exclusiva entre ambos
esta solucion no es posible pues son muchas maquinas distribuidas dentro de mi WAN.
- comprirmir del lado del cliente y descomprimir en el lado del servidor !!!
esta solucion me parece interesante, hacer que el aplicativo en visual basic, comprima las imagenes antes de enviarlas al servidor, que formato me recomendarian...?
- grabar en CD y llevar el CD hasta el server.
es una solucion muy costosa.
- tener paciencia y dejar copiando durante el final de semana !!!
podria ser una solucion.
esto es parte del archivo /var/log/vsftpd
[...]
Mon Jul 10 15:12:27 2006 [pid 4894] [bbva] FTP response: Client "10.10.10.10", "150 Ok to send data." Mon Jul 10 15:12:32 2006 [pid 4894] [bbva] OK UPLOAD: Client "10.10.10.10", "/Imagenes/Pecuza/108875.jpg", 121384 bytes, 25.54Kbyte/sec
la ip 10.10.10.10 es la tarjeta DMZ de mi proxy, el proxy es squid sobre Suse 9.1.
el trafico es de 25Kbytes/s y esto dentro de una red interna deberia de indicar algun problema con la (las) tarjetas de red o congestion en la propia red (cables/switchs) o algun limitador de ancho de banda.
la velocidad de 25kbps, es para una oficina remota de mi WAN, con 900k de ancho de banda. voy a verificar la velocidad desde mi LAN.
quedo en espera de sus sugerencias y comentarios.
por cierto, trabajas en un banco ?? por aca tenemos uno que se llama bbva, tambien !! ;-)
en realidad el banco es uno de nuestros clientes, nosotros nos encargamos de su mensajeria. Saludos JCarlos -- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
El 2006-07-10 a las 16:59 -0500, Juan Carlos Bravo Celis escribió:
- cambiar las actuales tarjetas de redes por modelos mas rapidos (gigabytes) !!!
las tarjetas son de 1Gbit
Pues 25 kb/s es ridículo. Habría que probar con un fichero de varios megas para medirlo realmente, porque el problema que tienes puede ser por la "negociación", son ficheros pequeños.
- comprirmir del lado del cliente y descomprimir en el lado del servidor !!!
esta solucion me parece interesante, hacer que el aplicativo en visual basic, comprima las imagenes antes de enviarlas al servidor, que formato me recomendarian...?
Pues precisamente JPG... ya están comprimidos al máximo, no vas a poder comprimirlos más. Podrías sacar un poquito más de rendimiento empaquetando (sin comprimir) unos cientos de ficheros en un único archivo, para evitar la latencia de la negociación fichero a fichero.
la velocidad de 25kbps, es para una oficina remota de mi WAN, con 900k de ancho de banda.
Ah, remota. Entonces esos 900k deduzco que son 900 kilobits/s, no 900 kilobytes/s, siguiendo la terminología habitual. O sea, casi una adsl. Si es así, 900 kilobits son unos 90 y pico kilobytes/s, y consigues 25, la cuarta parte; teniendo en cuenta que la red estará en uso por otra gente, y que el fichero es pequeño, me parece una velocidad normal. Además, si el sitio remoto tiene también una adsl, que no es simétrica, tendrá una velocidad de subida mucho menor, luego según eso la velocidad que consigues es francamente normal. Y si no, pues tendrás que explicarnos mejor la topología de la red. -- Saludos Carlos E. R. -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
On 10/07/06, Carlos E. R.
El 2006-07-10 a las 16:59 -0500, Juan Carlos Bravo Celis escribió:
- cambiar las actuales tarjetas de redes por modelos mas rapidos (gigabytes) !!!
las tarjetas son de 1Gbit
Pues 25 kb/s es ridículo. Habría que probar con un fichero de varios megas para medirlo realmente, porque el problema que tienes puede ser por la "negociación", son ficheros pequeños.
- comprirmir del lado del cliente y descomprimir en el lado del servidor !!!
esta solucion me parece interesante, hacer que el aplicativo en visual basic, comprima las imagenes antes de enviarlas al servidor, que formato me recomendarian...?
Pues precisamente JPG... ya están comprimidos al máximo, no vas a poder comprimirlos más.
Podrías sacar un poquito más de rendimiento empaquetando (sin comprimir) unos cientos de ficheros en un único archivo, para evitar la latencia de la negociación fichero a fichero.
la velocidad de 25kbps, es para una oficina remota de mi WAN, con 900k de ancho de banda.
Ah, remota. Entonces esos 900k deduzco que son 900 kilobits/s, no 900 kilobytes/s, siguiendo la terminología habitual. O sea, casi una adsl. Si es así, 900 kilobits son unos 90 y pico kilobytes/s, y consigues 25, la cuarta parte; teniendo en cuenta que la red estará en uso por otra gente, y que el fichero es pequeño, me parece una velocidad normal.
Además, si el sitio remoto tiene también una adsl, que no es simétrica, tendrá una velocidad de subida mucho menor, luego según eso la velocidad que consigues es francamente normal.
Y si no, pues tendrás que explicarnos mejor la topología de la red.
He realizado las pruebas desde mi red LAN, y aparece un error que es el siguiente: Tue Jul 11 12:51:09 2006 [pid 7217] [bbva] FTP command: Client "10.10.10.10", "STOR 119183.jpg" Tue Jul 11 12:51:09 2006 [pid 7217] [bbva] FTP response: Client "10.10.10.10", "150 Ok to send data." Tue Jul 11 12:51:09 2006 [pid 7217] [bbva] FTP response: Client "10.10.10.10", "426 Failure reading network stream." Tue Jul 11 12:51:09 2006 [pid 7217] [bbva] FAIL UPLOAD: Client "10.10.10.10", "/Imagenes/Peccpl/119183.jpg", 24576 bytes, 4321.99Kbyte/sec Tue Jul 11 12:56:09 2006 [pid 7217] [bbva] FTP response: Client "10.10.10.10", "421 Timeout." les explico un poco la configuracion de mi red, el servidor ftp se encuentra en la DMZ, entre este y mi LAN hay un servidor proxy con squid en suse 9.1 y que a su vez tiene el Susefirewall habilitado, segun estuve investigando, tengo que habilitarle el ip_contrack_ftp, podrian guiarme en como hacer esto? pues lo extraño es que desde mi wan si logran hacer la carga de imagenes y desde la lan, se produce este error. Saludos JCarlos -- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
On 11/07/06, Juan Carlos Bravo Celis
On 10/07/06, Carlos E. R.
wrote: El 2006-07-10 a las 16:59 -0500, Juan Carlos Bravo Celis escribió:
- cambiar las actuales tarjetas de redes por modelos mas rapidos (gigabytes) !!!
las tarjetas son de 1Gbit
Pues 25 kb/s es ridículo. Habría que probar con un fichero de varios megas para medirlo realmente, porque el problema que tienes puede ser por la "negociación", son ficheros pequeños.
- comprirmir del lado del cliente y descomprimir en el lado del servidor !!!
esta solucion me parece interesante, hacer que el aplicativo en visual basic, comprima las imagenes antes de enviarlas al servidor, que formato me recomendarian...?
Pues precisamente JPG... ya están comprimidos al máximo, no vas a poder comprimirlos más.
Podrías sacar un poquito más de rendimiento empaquetando (sin comprimir) unos cientos de ficheros en un único archivo, para evitar la latencia de la negociación fichero a fichero.
la velocidad de 25kbps, es para una oficina remota de mi WAN, con 900k de ancho de banda.
Ah, remota. Entonces esos 900k deduzco que son 900 kilobits/s, no 900 kilobytes/s, siguiendo la terminología habitual. O sea, casi una adsl. Si es así, 900 kilobits son unos 90 y pico kilobytes/s, y consigues 25, la cuarta parte; teniendo en cuenta que la red estará en uso por otra gente, y que el fichero es pequeño, me parece una velocidad normal.
Además, si el sitio remoto tiene también una adsl, que no es simétrica, tendrá una velocidad de subida mucho menor, luego según eso la velocidad que consigues es francamente normal.
Y si no, pues tendrás que explicarnos mejor la topología de la red.
He realizado las pruebas desde mi red LAN, y aparece un error que es el siguiente:
Tue Jul 11 12:51:09 2006 [pid 7217] [bbva] FTP command: Client "10.10.10.10", "STOR 119183.jpg" Tue Jul 11 12:51:09 2006 [pid 7217] [bbva] FTP response: Client "10.10.10.10", "150 Ok to send data." Tue Jul 11 12:51:09 2006 [pid 7217] [bbva] FTP response: Client "10.10.10.10", "426 Failure reading network stream." Tue Jul 11 12:51:09 2006 [pid 7217] [bbva] FAIL UPLOAD: Client "10.10.10.10", "/Imagenes/Peccpl/119183.jpg", 24576 bytes, 4321.99Kbyte/sec Tue Jul 11 12:56:09 2006 [pid 7217] [bbva] FTP response: Client "10.10.10.10", "421 Timeout."
les explico un poco la configuracion de mi red, el servidor ftp se encuentra en la DMZ, entre este y mi LAN hay un servidor proxy con squid en suse 9.1 y que a su vez tiene el Susefirewall habilitado, segun estuve investigando, tengo que habilitarle el ip_contrack_ftp, podrian guiarme en como hacer esto? pues lo extraño es que desde mi wan si logran hacer la carga de imagenes y desde la lan, se produce este error.
esto es lo que me muestra con un lsmod ip_conntrack_ftp 71856 1 ip_nat_ftp ip_conntrack 30768 6 ipt_MASQUERADE,ipt_REDIRECT,ipt_state,ip_nat_ftp,iptable_nat,ip_conntrack_ftp ese es el nombre correcto del modulo que necesito..? les paso mi vsftpd.conf para su opinion. write_enable=YES dirmessage_enable=YES ftpd_banner="Bienvenido al Servicio de Imagenes" local_enable=YES chroot_local_user=YES anonymous_enable=NO anon_world_readable_only=YES anon_upload_enable=NO anon_mkdir_write_enable=NO log_ftp_protocol=YES xferlog_enable=YES vsftpd_log_file=/var/log/vsftpd.log connect_from_port_20=YES pam_service_name=vsftpd ssl_enable=NO Saludos JCarlos -- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-07-11 a las 14:27 -0500, Juan Carlos Bravo Celis escribió:
He realizado las pruebas desde mi red LAN, y aparece un error que es el siguiente:
Ya, bueno, eso es un problema de cortafuegos, en el servidor, en el cliente, o incluso intermedio. Depende de si se usa ftp activo o pasivo, será un cortafuegos u otro - y no recuerdo nunca cual, me lo tengo que leer ;-)
les explico un poco la configuracion de mi red, el servidor ftp se encuentra en la DMZ, entre este y mi LAN hay un servidor proxy con squid en suse 9.1 y que a su vez tiene el Susefirewall habilitado, segun estuve investigando, tengo que habilitarle el ip_contrack_ftp, podrian guiarme en como hacer esto? pues lo extraño es que desde mi wan si logran hacer la carga de imagenes y desde la lan, se produce este error.
Eso es para la lan. Pero hablamos del caso remoto, con la wan, como transmites de un sitio a otro, con qué conexión. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEtD2/tTMYHG2NR9URAk35AKCGn5EwBpd2NjXEYPgaZt3urjH53wCfZZwQ gw+tLO/4z4XSZ4Y/ShO0pYM= =413e -----END PGP SIGNATURE----- -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
On 11/07/06, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2006-07-11 a las 14:27 -0500, Juan Carlos Bravo Celis escribió:
He realizado las pruebas desde mi red LAN, y aparece un error que es el siguiente:
Ya, bueno, eso es un problema de cortafuegos, en el servidor, en el cliente, o incluso intermedio. Depende de si se usa ftp activo o pasivo, será un cortafuegos u otro - y no recuerdo nunca cual, me lo tengo que leer ;-)
les explico un poco la configuracion de mi red, el servidor ftp se encuentra en la DMZ, entre este y mi LAN hay un servidor proxy con squid en suse 9.1 y que a su vez tiene el Susefirewall habilitado, segun estuve investigando, tengo que habilitarle el ip_contrack_ftp, podrian guiarme en como hacer esto? pues lo extraño es que desde mi wan si logran hacer la carga de imagenes y desde la lan, se produce este error.
Eso es para la lan. Pero hablamos del caso remoto, con la wan, como transmites de un sitio a otro, con qué conexión.
Mi wan, se conecta a traves de tecnologia ADSL, y algunos enlaces MPLS, los enlaces ADSL son de 900/256 kbps mas un canal de voz, ninguno de los enlaces pasa por internet, mi oficina principal tiene un ancho de banda de 2MB MPLS para la WAN, y una conexion a internet de 2MB 1:1, entre el router de mi WAN y mi router de salida a internet tengo un proxy firewall que me da acceso a mi DMZ y a un firewall principal que da cara a internet. segun calculos y consultas estoy de acuerdo en que 25kbps de subida para los archivos me parece que es aceptable, cada oficina remota usa el mismo usuario para transferir los archivos, ( no lo hacen al mismo tiempo) , cada una sube las imagenes a una carpeta diferente que ayuda a identificarlas, en la carpeta que usan los equipos de mi LAN, hasy 100000 imagenes, y en los de mis oficinas remotas apenas 15000 en promedio, las remotas si transfieren sin problemas, pero las de mi LAN, les retorna un mensaje de Timeout. Creen que este Timeout, se deba a la cantidad de archivos que hay en esa carpeta? tiene un limite la cantidad de archivos en una carpeta? estoy usando reiserfs. Saludos JCarlos
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-07-12 a las 13:01 -0500, Juan Carlos Bravo Celis escribió:
Mi wan, se conecta a traves de tecnologia ADSL, y algunos enlaces MPLS, los enlaces ADSL son de 900/256 kbps mas un canal de voz, ninguno de los enlaces pasa por internet, mi oficina principal tiene un ancho de banda de 2MB MPLS para la WAN, y una conexion a internet de 2MB 1:1, entre el router de mi WAN y mi router de salida a internet tengo un proxy firewall que me da acceso a mi DMZ y a un firewall principal que da cara a internet.
segun calculos y consultas estoy de acuerdo en que 25kbps de subida para los archivos me parece que es aceptable, cada oficina remota usa el mismo usuario para transferir los archivos, ( no lo hacen al mismo tiempo) , cada una sube las imagenes a una carpeta diferente que ayuda a identificarlas, en la carpeta que usan los equipos de mi LAN, hasy 100000 imagenes, y en los de mis oficinas remotas apenas 15000 en promedio, las remotas si transfieren sin problemas, pero las de mi LAN, les retorna un mensaje de Timeout.
Creen que este Timeout, se deba a la cantidad de archivos que hay en esa carpeta? tiene un limite la cantidad de archivos en una carpeta? estoy usando reiserfs.
No hay limite conocido. Oficialmente, no hay límite. Yo hice una probatina de crear muchísimos ficheros, y no recuerdo si creé cien mil o un millón. Puse la prueba en la lista; pero no recuerdo cuando, si no te lo concretaría. Es que no caigo en una palabra clave para buscarlo. ¿Se acuerda alguien? No, yo pensaría que el problema debe ser cuestión de cortafuegos con el protocolo ftp. Podrías probar con el protocolo ssh, que no tiene ese tipo de problemas. Bueno, no ssh, sino sftp, pero es de la familia. Es un poquito más lento, por la encriptación, pero tu cuello de botella es la adsl, no la potencia de cálculo. Puedes comprobarlo enviando un fichero a un directorio con poca ocupación, a ver si da timeout. También se vería en el log del servidor ftp. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEtUIutTMYHG2NR9URAleWAJ4unWNqDRYGgMMdL+W5ZGWlpk59ewCfZeW1 fwqRywgyPn3aH1Weop2cr4k= =q8Dz -----END PGP SIGNATURE-----
Hola :) El Miércoles, 12 de Julio de 2006 20:40, Carlos E. R. escribió:
El 2006-07-12 a las 13:01 -0500, Juan Carlos Bravo Celis escribi�:
Mi wan, se conecta a traves de tecnologia ADSL, y algunos enlaces MPLS, los enlaces ADSL son de 900/256 kbps mas un canal de voz, ninguno de los enlaces pasa por internet, mi oficina principal tiene un ancho de banda de 2MB MPLS para la WAN, y una conexion a internet de 2MB 1:1, entre el router de mi WAN y mi router de salida a internet tengo un proxy firewall que me da acceso a mi DMZ y a un firewall principal que da cara a internet.
segun calculos y consultas estoy de acuerdo en que 25kbps de subida para los archivos me parece que es aceptable, cada oficina remota usa el mismo usuario para transferir los archivos, ( no lo hacen al mismo tiempo) , cada una sube las imagenes a una carpeta diferente que ayuda a identificarlas, en la carpeta que usan los equipos de mi LAN, hasy 100000 imagenes, y en los de mis oficinas remotas apenas 15000 en promedio, las remotas si transfieren sin problemas, pero las de mi LAN, les retorna un mensaje de Timeout.
Creen que este Timeout, se deba a la cantidad de archivos que hay en esa carpeta? tiene un limite la cantidad de archivos en una carpeta? estoy usando reiserfs.
No hay limite conocido. Oficialmente, no hay l�mite. Yo hice una probatina de crear much�simos ficheros, y no recuerdo si cre� cien mil o un mill�n. Puse la prueba en la lista; pero no recuerdo cuando, si no te lo concretar�a. Es que no caigo en una palabra clave para buscarlo. �Se acuerda alguien?
Teóricamente no hay límite, pero en la práctica puedes encontrarte con problemas de rendimiento. Creo que comenté en correos anteriores que nosotros aconsejamos a nuestros clientes no meter más de 15000 ficheros en cada directorio si un MS-Windows va a tener que acceder a él porque el MS-Windows puede tener problemas para listarlos. En el caso de Linux, tenemos clientes gringos con 70 millones de ficheros. A veces tarda un poco, pero no es problemático. En pruebas internas hemos montado sistemas de ficheros con 400 millones de ficheros y un rendimiento aceptable. De todas maneras, no aconsejamos tener más de 40 millones de ficheros porque puedes ver problemas de rendimiento, gestión, ...
No, yo pensar�a que el problema debe ser cuesti�n de cortafuegos con el protocolo ftp. Podr�as probar con el protocolo ssh, que no tiene ese tipo de problemas. Bueno, no ssh, sino sftp, pero es de la familia. Es un poquito m�s lento, por la encriptaci�n, pero tu cuello de botella es la adsl, no la potencia de c�lculo.
Puedes comprobarlo enviando un fichero a un directorio con poca ocupaci�n, a ver si da timeout. Tambi�n se ver�a en el log del servidor ftp.
Yo estoy con Calros, creo que más bien es algo de red. De todas maneras, prueba iperf para medir el ancho de banda que tienes. Una vez hecho eso, prueba con un dd (existe dd para MS-Windows) desde MS-Windows a escribir y leer en el Linux. Estas son las dos pruebas que suelo usar porque iperf mide sólo ancho de banda y dd permite medir ancho de banda y acceso a disco así como consumo de CPU. Si alguien tiene curiosidad ... que pruebe a montar un tmpfs en RAM (o un RAMDISK) y que lance un dd ... la CPU es el cuello de botella :( HTH Rafa -- "Even paranoids have enemies." Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com OpenWengo: rgriman Skype: rgriman
On 13/07/06, Rafa Grimán
Hola :)
El Miércoles, 12 de Julio de 2006 20:40, Carlos E. R. escribió:
El 2006-07-12 a las 13:01 -0500, Juan Carlos Bravo Celis escribi�: [...] No, yo pensar�a que el problema debe ser cuesti�n de cortafuegos con el protocolo ftp. Podr�as probar con el protocolo ssh, que no tiene ese tipo de problemas. Bueno, no ssh, sino sftp, pero es de la familia. Es un poquito m�s lento, por la encriptaci�n, pero tu cuello de botella es la adsl, no la potencia de c�lculo.
Puedes comprobarlo enviando un fichero a un directorio con poca ocupaci�n, a ver si da timeout. Tambi�n se ver�a en el log del servidor ftp.
Realice la prueba de enviar archivos a una carpeta vacia, y de 50 que se enviaban solo se concretaban 8 o 10 de manera aleatoria.
Yo estoy con Calros, creo que más bien es algo de red. De todas maneras, prueba iperf para medir el ancho de banda que tienes. Una vez hecho eso, prueba con un dd (existe dd para MS-Windows) desde MS-Windows a escribir y leer en el Linux.
Finalmente descubri, que habia algo malo en la Red y era el Windows XP, pues realizamos la prueba con una PC con Windows 98, y todo va de maravilla, pasa 12800 imagenes y no se queja,, y menos mi servidor que es linux, no le hace ni cosquillas.
Estas son las dos pruebas que suelo usar porque iperf mide sólo ancho de banda y dd permite medir ancho de banda y acceso a disco así como consumo de CPU. Si alguien tiene curiosidad ... que pruebe a montar un tmpfs en RAM (o un RAMDISK) y que lance un dd ... la CPU es el cuello de botella :(
voy a realizar algunas de estas pruebas y a investigar por que el Windows XP, genera problemas, pero eso es otro tema. Muchas gracias a todos por su ayuda, creame que aprendi mucho estos dias. Saludos JCarlos
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-07-13 a las 18:17 -0500, Juan Carlos Bravo Celis escribió:
voy a realizar algunas de estas pruebas y a investigar por que el Windows XP, genera problemas, pero eso es otro tema.
Prueba en el XP con otro cliente, uno que te permita elegir ftp activo o pasivo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEtuEDtTMYHG2NR9URAo0dAJ9sz60YpMFGS/DesqkXCZSXUF0qOwCfUFwJ XnE8mdqo77UZdzV6g77owCo= =lrpv -----END PGP SIGNATURE----- -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
Hola :) El Lunes, 10 de Julio de 2006 23:59, Juan Carlos Bravo Celis escribió:
On 10/07/06, Victor Hugo dos Santos
wrote: 2006/7/10, Juan Carlos Bravo Celis
: Estimados, tengo un servidor de imagenes en Suse 10.1, al cual se suben images desde un software desarrollado en Visual Basic usando ftp. Para esto, instale vsftp, diariamente se suben aprox 20,000 imagenes, pero el proceso es demasiado lento, pues para subir 1000 archivos se tarda aproximadamente 1 hora 30 minutos, ahora mi pregunta es la siguiente, hay alguna forma de hacer que la transferencia, sea mas rapida?
- disminuir el tamano de las imagens con menos calidad y/o algun formato distinto !!!
imposible, estan al minimo, se requiere que las imagenes sean en formato jpg. 150k aprox por imagen
Pues aquí tienes un problema. Me explico: 20 k ficheros * 150 KBytes por fichero = 3000000 KB 3000000 KB = 2,929.6875 MB = 2,86 GB Estás transfiriendo 2,86 GB usando una conexión de 25 kbps ... Normal que te vaya lento :"(
- cambiar las actuales tarjetas de redes por modelos mas rapidos (gigabytes) !!!
las tarjetas son de 1Gbit
¿Puedes hacer channel bonding en el servidor? [...]
- comprirmir del lado del cliente y descomprimir en el lado del servidor !!!
esta solucion me parece interesante, hacer que el aplicativo en visual basic, comprima las imagenes antes de enviarlas al servidor, que formato me recomendarian...?
JPEG ya es un formato comprimido, no creo que puedas comprimir mucho más. En todo caso, puedes usa 7zip que comprime mucho. Si tienes los fuentes del programa, puedes introducir una novedad y es que detecte el estado de la conexión de red, si no se usa la red ... empieza a subir ficheros, i la red está en uso ... deja de subir ficheros. [...]
- tener paciencia y dejar copiando durante el final de semana !!!
podria ser una solucion.
Esta es la que más me gusta. Otra opción similar es transferir de noche. Dudas que me surgen: - ¿puedes montar un servidor en cada oficina? La idea es tener en cada sede/oficina un servidor que recopila todas las imágenes de los PCs y así sólo hay una conexión por oficina/sede. No te va a mejorar el ancho de banda, pero vas a disminuir el número de conexiones que recibe el servidor ... ya es algo. - posiblemente la opción anterior no se pueda hacer o sea cara, ... por lo que nos queda tu servidor, el que recibe todo vía FTP. ¿Lo has monitorizado? ¿Tiene cuellos de botella? ¿Qué HW tiene? ¿Usas jumbo frames? ¿Cuántas tarjetas de red tienes? Te pregunto todo esto porque: - si no usas jumbo frames, cada paquete (1.5 K) que recibe = una interrupción. Si usas jumbo frames, cada paquete son 9 K por lo que el número de interrupciones es menor ... luego la CPU no sufre tanto. - el número de tarjetas de red te va a aumentar el número de interrupciones por lo que la CPU va a sufrir - monitoriza la CPU para ver si es un cuello de botella por lo que te he comentado antes - monitoriza la memoria porque si va a recibir 3 GB de datos, recuerda que Linux usa toda la memoria que puede. - monitoriza los discos y el sistema de ficheros porque pueden suponer otro cuello de botella, son 20 K ficheros relativamente pequeños. Pon noatime en el /etc/fstab de forma que no se escriba la fecha de acceso a fichero, esto te evita 2 accesos a disco para cada fichero - ¿los discos son locales o es una cabina SAN? ¿Son SATA, ATA, SCSI, FC? Esto también te puede dar mejoras de rendimiento en función del tipo y su configuración. - ¿cuántos ficheros maneja el servidor? No es recomendable que una partición maneje más de 40 millones de ficheros y tampoco es recomendable que un directorio accedido por MS-Windows tenga más de 15 mil ficheros. - ¿qué sistema de ficheros usas? reiserfs es muy bueno con fiheros de 4 K, pero no es bueno si el sistema de ficheros tiene mucha E/S y ficheros que se modifican mucho. XFS y ext3 son bastante todo terreno, aunque XFS está más orientado a ficheros grandes. JFS da problemas si está cargado como módulo - ¿cuántas CPUs tienes? - ¿cuántos dispositivos tienes conectados y funcionando? Recuerda lo que te he comentado anteriormente de las interrupciones ... Quita los dispositivos que se estén usando y no estén configurados. - monitoriza tu red por si hay alguien usándola "incorrectamente" aka e-donkey y familia Hay muchas más preguntas en cuanto a HW, pero de todas maneras creo que el cuello de botella es la conexión ... 25 kbps es poco, especialmente si son muchas conexiones. Intenta conseguir mejorar esto: reduciendo el número de conexiones, aumentando el ancho de banda, realizando las conexiones cuando la gente no usa la red (de noche, fines de semana, ...), ... HTH Rafa -- "Even paranoids have enemies." Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com OpenWengo: rgriman Skype: rgriman -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
2006/7/10, Juan Carlos Bravo Celis
On 10/07/06, Victor Hugo dos Santos
wrote: 2006/7/10, Juan Carlos Bravo Celis
:
[...]
- cambiar las actuales tarjetas de redes por modelos mas rapidos (gigabytes) !!!
las tarjetas son de 1Gbit
mmm.. mas abajo especificas que tienes una WAN, o sea,oficinas remotas.. en este caso, no importa mucho que tengas una tarjeta de 1Gbit o 10Gbit o 10Mbits.. ya que todo va estar limitado por el ancho de banda de vuestro enlace a las WANs. [...]
- grabar en CD y llevar el CD hasta el server.
es una solucion muy costosa.
pedistes ideas para solucionar el problema, nunca mencionaste costos !!! ;-) ademas, que no seas tan tacaño.. unos 5 CDs o 1 DVD no debe de costar tanto !!! :-D [...]
el trafico es de 25Kbytes/s y esto dentro de una red interna deberia de indicar algun problema con la (las) tarjetas de red o congestion en la propia red (cables/switchs) o algun limitador de ancho de banda.
la velocidad de 25kbps, es para una oficina remota de mi WAN, con 900k de ancho de banda.
aahhhh.... 25kbytes * 8 = 200Kbits o sea.. estas utilizando aproximadamente 25% del enlace de vuestra WAN.. ahora, se consideramos que "puede" que existan otros usuarios/aplicativos utilizando este mismo enlace, entonces no hay nada de anormal... Del contrario, se el enlace es "exclusivo" para vuestra aplicacion (cosa que lo dudo mucho, ya que segun usted mismo tienes muchos usuarios/pcs) entonces deberias de reclamar con el provedor del enlace, ayq ue el mismo no esta funcionando como deberias. por cierto, antes de ir a reclamar, verifica el enlace con "iptraf" !!! salu2 -- -- Victor Hugo dos Santos Linux Counter #224399 -- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
desde cuantas maquinas se suben archivos???, estan en una LAN, VPN por Internet, que tamaño de archivo son??, pasas por un proxi, para llegar al ftp?? routers?? Juan Carlos Bravo Celis escribió:
Estimados, tengo un servidor de imagenes en Suse 10.1, al cual se suben images desde un software desarrollado en Visual Basic usando ftp. Para esto, instale vsftp, diariamente se suben aprox 20,000 imagenes, pero el proceso es demasiado lento, pues para subir 1000 archivos se tarda aproximadamente 1 hora 30 minutos, ahora mi pregunta es la siguiente, hay alguna forma de hacer que la transferencia, sea mas rapida?
esto es parte del archivo /var/log/vsftpd
Mon Jul 10 15:12:27 2006 [pid 4894] [bbva] FTP response: Client "10.10.10.10", "226 File receive OK." Mon Jul 10 15:12:27 2006 [pid 4894] [bbva] FTP command: Client "10.10.10.10", "TYPE I" Mon Jul 10 15:12:27 2006 [pid 4894] [bbva] FTP response: Client "10.10.10.10", "200 Switching to Binary mode." Mon Jul 10 15:12:27 2006 [pid 4894] [bbva] FTP command: Client "10.10.10.10", "PORT 10,10,10,10,6,121" Mon Jul 10 15:12:27 2006 [pid 4894] [bbva] FTP response: Client "10.10.10.10", "200 PORT command successful. Consider using PASV." Mon Jul 10 15:12:27 2006 [pid 4894] [bbva] FTP command: Client "10.10.10.10", "STOR 108875.jpg" Mon Jul 10 15:12:27 2006 [pid 4894] [bbva] FTP response: Client "10.10.10.10", "150 Ok to send data." Mon Jul 10 15:12:32 2006 [pid 4894] [bbva] OK UPLOAD: Client "10.10.10.10", "/Imagenes/Pecuza/108875.jpg", 121384 bytes, 25.54Kbyte/sec
la ip 10.10.10.10 es la tarjeta DMZ de mi proxy, el proxy es squid sobre Suse 9.1.
quedo en espera de sus sugerencias y comentarios.
Saludos
JCarlos
-- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
participants (5)
-
Carlos E. R.
-
Juan Carlos Bravo Celis
-
Mario Tello
-
Rafa Grimán
-
Victor Hugo dos Santos