Que un server este yendo al 100% de ultima es inevitable. O sea, nadie se espanta si la maquina de uno, que puede correr N threads, se va al 100% si lo que estas haciendo es compactar video con N threads. El tema es 100% de que. Seria un problema mucho mas grande que el CPU se fuera al 100% y que top diga algo como "si, 100% de CPU, de lo cual el 70% es I/O wait". Si hay 100% de CPU y casi nada de I/O wait, entonces el hardware esta haciendo lo que corresponde.
Ahora bien, si el 100% es por busqueda lineal de 'Leo', entonces hay que cambiar el algoritmo y hacer que ese 100% de CPU sea mas eficiente en terminos de lograr el resultado que uno busca. 2013/9/20 <[email protected]> > Andres, justamente eso hicimos, ejecutamos un top en el server y > comprobamos que no habia demasiados problemas de I/O, en cambio si al > ejecutar un informe el proceso topaz se va al 100% al toque (lo que no > puedo distinguir es que procesador se va al 100 o si son los 4, si hubiera > alguna forma de ver esto agradeceria el consejo). > > Efectivamente el nuevo hard donde hicimos la prueba tiene mejor procesador > y seguramente influyo en la mejora que percibimos alli. > > saludos! > > Leo > > *----- Original Message -----* > *From:* Andres Valloud [mailto:[email protected]] > *To:* [email protected] > *Sent:* Fri, 20 Sep 2013 05:14:17 -0700 > *Subject:* Re: [clubSmalltalk] GLASS perfomance & bug detector > > Si el problema tiene que ver con I/O, entonces cualquier profiler del > server mismo deberia mostrarlo... top en Linux, por ejemplo, suele mostrar > cuanto tiempo se va en I/O wait. Eso no quiere decir que acelerar el I/O > vaya a resolver el problema de fondo, ya que un exceso aparente de I/O > puede ser consecuencia de por ejemplo lo que dijo Carlos acerca de replicar > objetos en vez de forwardear requests. No me quedo claro si los reportes > de ejecutan del lado del cliente o del lado del server. > > > 2013/9/19 Leonardo Andres De Marco <[email protected]> > > Hola a todos! > > estoy laburando en un proyecto que tienen un sistema ya funcionando en > producción hecho con GLASS. > > Debuging: > > Ahora bien, al principio buscar errores que el usuario me reportaba pude > salir victorioso gracias a los propios Halos+inspector seaside + Gemtools > me las arregle bien (sin conocer bien el modelo). > > Preguntonta: Existe la posibilidad de hacer un snapshot de esa imagen > corriendo en gemstone y levantarla en un pharo? si? no? consejos para > trabajar con datos Pharo sin gemstone? o volcar parte de la info para > trabajar mas comodo? > > > Performance: > > Por otra parte, el sistema estuvo funcionando un tiempo muy bien, a nivel > de funcionalidad estan contentos, perooo, estan teniendo problemas de > performance sobre todo en la ejecucion de informes (los informes en este > sistema generan mucha basura, pero incluso pasando el GC a manopla el > sistema presenta lentitud en la ejecucion e esos informes). Estuvimos > viendo este post > http://gemstonesoup.wordpress.com/2009/02/28/approaching-the-speed-of-light-ssd-drives-for-gemstones/ > en > donde Hernan inlcuso comenta la mejora con discos SSD por problemas de i/o. > Para sacarnos la duda, montamos el sistema en un servidor externo con > discos SSD y si bien vimos una mejora de perfomance notable, luego montamos > el mismo sistema en discos "comunes" y la mejora seguia, por lo que > asumimos que el tema es de hardware... asi y todo, el servidor actual no es > tan chiquito (tiene 8 procesadores y 8GB ram) de los cuales, la VM de > gemstone usa 4cpu y 6 GB ram (la base de gemstone pesa 14GB pero tiene > pocos usuarios concurrentes, unos 10 usuarios.). > > Conclusion: queremos estar seguros que sea solamente un tema de hard o hay > algo mejorable en el sistema (seguro q lo hay, pero algo que sea bien > notable que este provocando esos cuellos de botella). Finalmente pregunto: > existe un profiler o algo similar en gemstone que me permita monitorear eso > o que tecnica recomiendan para detectar este tipo de problemas? > > gracias, > Leo > > -- > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > mailto:clubsmalltalk%[email protected]<clubsmalltalk%[email protected]> > > http://www.clubSmalltalk.org > --- > Has recibido este mensaje porque estás suscrito al grupo "ClubSmalltalk" > de Grupos de Google. > Para anular la suscripción a este grupo y dejar de recibir sus correos > electrónicos, envía un correo electrónico a > mailto:clubsmalltalk%[email protected]<clubsmalltalk%[email protected]> > . > Para obtener más opciones, visita https://groups.google.com/groups/opt_out > . > > > -- > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org > --- > Has recibido este mensaje porque estás suscrito al grupo "ClubSmalltalk" > de Grupos de Google. > Para anular la suscripción a este grupo y dejar de recibir sus correos > electrónicos, envía un correo electrónico a > [email protected]. > Para obtener más opciones, visita https://groups.google.com/groups/opt_out > . > > -- > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org > --- > Has recibido este mensaje porque estás suscrito al grupo "ClubSmalltalk" > de Grupos de Google. > Para anular la suscripción a este grupo y dejar de recibir sus correos > electrónicos, envía un correo electrónico a > [email protected]. > Para obtener más opciones, visita https://groups.google.com/groups/opt_out > . > -- -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org --- Has recibido este mensaje porque estás suscrito al grupo "ClubSmalltalk" de Grupos de Google. Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a [email protected]. Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
