Re: [bofhers] Garbage collector de .NET
- From: vfmBOFH <vfmbofh@xxxxxxxxx>
- To: bofhers <bofhers@xxxxxxxxxxxxx>
- Date: Tue, 6 May 2014 14:08:51 +0200
El 6 de mayo de 2014, 14:03, SinnerBOFH <sinnerbofh@xxxxxxxxx> escribió:
> ¿Programador HINGENIERO Gafapastoide?
>
> Es que me lo imagino, en plan Modernet De Merda con un WindowsPhone
> Chupiguai
>
> A todo esto, recuerdo como PoetaBOFH derribó un MySQL tuneado en un
> Proliant nuevecito al no cerrar las conexiones a la base de datos. En
> PEHACHEPE fuloso.
>
**************************************************************************************
> Su solución era meter un cronjob para reiniciar el servidor por la noche.
>
>
**************************************************************************************
A ver qué te crees tú que tengo montado yo en la rubia para que el MySQL de
Blogdrake aguante xD. El Drupal ha pasado por tantas manos que no hay por
dónde atacar para plantearse siquiera una actualización.
> Ejqueeee
>
> Salut,
> SinnerBOFH
>
> On May 5, 2014, at 8:21 PM, vfmBOFH <vfmbofh@xxxxxxxxx> wrote:
>
> En este caso concreto, es que el programador es así de estupendo, el
> hombre...
>
>
> BTW, correo enviado desde mi flamante instalación de Open-Xchange. Mola QTC
>
>
> El 6 de mayo de 2014 a las 1:31 Wardog <wardogyelmundo@xxxxxxxxx>
> escribió:
>
> Los programadores suelen sobreestimar el tiempo "perdido" en conectar a
> la base de datos pero se la pela muchísimo optimizar las consultas y los
> bloqueos de tabla. He visto cosas que no creeríais. Esas dos simples
> chorradas bien hechas me han conseguido aumentos de rendimiento del 4.000%
>
>
> El 6 de mayo de 2014, 0:54, vfmBOFH <vfmbofh@xxxxxxxxx> escribió:
>
>> +1 a la sobredosis de conexiones. No hace ni 20 días que tuvimos un caso
>> similar en fotofriki: La super aplicación web no cerraba conexiones y se
>> encargó de tumbar un maquinón con un Oracle tuneado más que competentemente
>> a base de conexiones sin cerrar.
>>
>>
>>
>>
>> El 6 de mayo de 2014, 0:46, Wardog <wardogyelmundo@xxxxxxxxx>escribió:
>>
>> Voto por lo mismo. Si no cierras las conexiones a la base de datos
>>> aquello empieza a devorarse a sí mismo a poco que le des candela. Ojo
>>> también al ámbito de datareaders y qué se deja ahí metido.
>>>
>>>
>>> El 5 de mayo de 2014, 23:53, f5inet <f5inet@xxxxxxxxx>escribió:
>>>
>>> suena a que las conexiones a la BBDD no se cierran explicitamente en
>>>> el webservice y se queda con mogollon de conexiones a la BBDD abiertas.
>>>> hasta que no se reinicia el runtime o se fuerza un GC no se liberan
>>>> 'implicitamente' las conexiones.
>>>>
>>>> de todas maneras, creo que una llamada a System.GC.Collect() deberia
>>>> ser suficiente.
>>>>
>>>> te recomendaria hacer un LOG en cada webservice, que logueara el
>>>> resultado de GC.GetTotalMemory(false), y ver si a partir de cierta memoria
>>>> ocupada empieza a quedarse tonto el webservice. si es asi, con hacer que se
>>>> ejecute el GC.Collect() si lo que devuelva GC.GetTotalMemory(false) es mas
>>>> del 50% de cuando se queda tonto, deberia ser suficiente.
>>>>
>>>> tambien es posible que necesites llamar a GC. WaitForPendingFinalizers(),
>>>> para asegurarte que los objetos 'tontos' son finalizados correctamente
>>>> antes de seguir ejecutando codigo y metiendo mas basura al Heap.
>>>>
>>>>
>>>> El 5 de mayo de 2014, 21:43, Carlos Melgarejo
>>>> <zerocool.cmg@xxxxxxxxx>escribió:
>>>>
>>>>
>>>> Buenas noches BOFHmanos,
>>>>>
>>>>> Tengo un problema con el GC de .NET y me gustaría saber si alguno lo
>>>>> ha tenido y como lo puedo solucionar.
>>>>>
>>>>> Expongo el pifostio:
>>>>>
>>>>> Tengo una aplicación, la cual saca chicha de una bbdd
>>>>> (irremediablemente) SQLServer. En un principio estaba App -> BBDD, todo
>>>>> funcionando a la perfección y la hostia de rápido.
>>>>>
>>>>> Llego el momento en el que el cliente pidió un WebService, y debía
>>>>> ser en .NET C#.
>>>>>
>>>>> Aquí viene el problema, el WS, tras 3 o 4 días, se queda atontado y
>>>>> bloquea todo el sistema de datos, teniendo que reiniciar el site de IIS.
>>>>>
>>>>> En uno de los bloqueos, dijimos a los técnicos (por llamarlos de
>>>>> alguna manera) que no reiniciaran, y lanzamos un forzado de limpieza de
>>>>> GC,
>>>>> dando en la clave del bloqueo. Al limpiarse, volvió a la vida la
>>>>> criaturita.
>>>>>
>>>>> Entonces, sabéis de alguna forma de que no pase esto con el
>>>>> Recolector?
>>>>>
>>>>> La última opción es poner un forzado de limpieza cada noche, o
>>>>> incluso (mucho mas hardcore) un forzado de limpieza, al final de cada
>>>>> petición.
>>>>>
>>>>> Muchas gracias por las respuestas que podáis dar.
>>>>>
>>>>> Un saludo y a cuidarse.
>>>>>
>>>>
>>>>
>>>
>>
>
>
>
>
Other related posts:
