Estado conexiones TCP/NAT

[Horst von Brand]

"Miguel Oyarzo O." <admin en aim.cl> dijo:

[...]

> Mira estos resultados y dime que opinas:
> 
> # cat /proc/net/ip_conntrack |wc -l         (asi estoy contando las 
> conexiones abiertas.. se me olvido mencionarlo)
> 24310
> 
> Basado en tus comentarios:
> 
> # grep ip_conntrack /proc/slabinfo
> ip_conntrack       25526  28450    384 2808 2845    1
> 
> 24310 serian las conexiones abiertas y 25526 el numero de objetos
> ip_conntrack usados por el kernel y activos en la memoria.

Y?

> Al parecer que el objeto ip_conntrack  se mantiene en memoria un tiempo...
> pero cuánto?  quien determina su duracion TTL?

Administracion de memoria del nucleo: Se crean slabs (una coleccion de
objetos del mismo tipo que cabe en una pagina o asi), y se administran de
alli. Obviamente habran slabs con algunos objetos libres (sin usar). Se
mantienen en memoria mientras el slab contenga objetos activos. Y un slab
sin objetos activos puede mantenerse siempre que no haya presion por
asignar memoria (porque es ideal reusar un objeto ya inicializado, &c).

Quien determina la vida del objecto? En este caso, la duracion de la
conexion... y sobre eso no hay control en el nucleo. Enseguida, los RFC
requieren mantener historia sobre una conexion cerrada durante un tiempo
bastante largo para evitar que se cruzen los alambres.

> Opiciones? comentarios?
> Esta interesante este tema...  optimizar ese cache será una buena idea.

Comienza por estudiar el manejo de memoria virtual (y administracion de
memoria en general) en el nucleo. Es un area extremadamente entretenida,
con solo unos pocos gurues que saben suficiente para atreverse a meter
mano... Si, la idea de compactar slabs (moviendo objetos entre slabs
semivacios para liberar alguno) se ha discutido muchas veces. No, no hay
propuestas concretas viables. En buena parte porque eso significaria tener
maquinaria para cambiarle la direccion a un objeto, corrigiendo /todas/ las
referencias a el... y no hay como saber cuales son (y la maquinaria para
seguirle el paso a eso seguramente seria inmensa, compleja, ineficiente, y
fragil). Otra idea es ver de asignar nuevos objetos con alguna heuristica
que deje juntos objetos de vidas largas y cortas... buena suerte!

Y antes de tirarse por ese camino: De cuanta memoria estamos hablando? No
resulta mas facil ponerle un par de MiB mas al tarro?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513