Configuración Apache sobre Windows - informix 9.21 - Php

SIU-Guaraní SIU-Guaraní 2 - Técnicos
1

Hola,

les escribo para comentarles un problema que no está pasando en forma aleatoria con el Guarani 3W.

Nuestra configuración Actual es la siguiente:

Windows 2003 Server
PHP 5.2.13
Apache 2.2
Conexión mediante adodb a la base
Cliente de Informix 9.51 2.70 TC1

Ante diversos problemas de contención que hemos tenido, hemos decidido mover los sitio de IIS a Apache, manteniendo la plataforma del sistema operativo, Windows.

Hemos realizado pruebas, modificando la función conectar() de la libería std_functions.lib.php, cambiando la invocación a connect() por pconnect() para mantener conexiones persistentes y que se reusen, debido a que notabamos que se generaban muchas conexiones por cada acceso al sitio.

Esto solucionó en forma inmediata el problema del acceso al web en particular para inscripciones masivas con cupo, pero trajo algunos problemas de “Out of Memory” en forma aleatoria, dejando el servicio Apache caido. Además genera muchisima alocación de memoria en el motor de base de datos que no se utilizaba y nunca se liberaba.

Los errores en el web aparecen en forma aleatoria, teniendo aparentemente como origen la libería de adodb, que es la estamos utilizando y la cual fue provista en la versión actual de Guarani 3W.

Hemos variado las configuraciones de Apache sin exito alguno, modificando los parámetros tanto del servidor apache como del php.ini , sin lograr exito, debido a que por más que el equipo cuente con 16 Gb de RAM, se cuelga el proceso Apache.
Les copio las partes importantes de la configuración de php y apache para poder cotejar con Uds y que puedan contar la experiencia de Uds en sus instalaciones.

(php.ini) PHP

max_execution_time = 180 ; Maximum execution time of each script, in seconds
max_input_time = 60 ; Maximum amount of time each script may spend parsing request data
;max_input_nesting_level = 64 ; Maximum input variable nesting level
memory_limit = 128M ; Maximum amount of memory a script may consume (128MB)

[Informix]
; Default host for ifx_connect() (doesn’t apply in safe mode).
ifx.default_host =

; Default user for ifx_connect() (doesn’t apply in safe mode).
ifx.default_user =

; Default password for ifx_connect() (doesn’t apply in safe mode).
ifx.default_password =

; Allow or prevent persistent links.
ifx.allow_persistent = On

; Maximum number of persistent links. -1 means no limit.
ifx.max_persistent = -1

; Maximum number of links (persistent + non-persistent). -1 means no limit.
ifx.max_links = -1

; If on, select statements return the contents of a text blob instead of its id.
ifx.textasvarchar = 0

; If on, select statements return the contents of a byte blob instead of its id.
ifx.byteasvarchar = 0

; Trailing blanks are stripped from fixed-length char columns. May help the
; life of Informix SE users.
ifx.charasvarchar = 0

; If on, the contents of text and byte blobs are dumped to a file instead of
; keeping them in memory.
ifx.blobinfile = 0

; NULL’s are returned as empty strings, unless this is set to 1. In that case,
; NULL’s are returned as string ‘NULL’.
ifx.nullformat = 0

En relación a lo de PHP hemos leido que las variables de ifx de este archivo no tienen injerencia en las nuevas versiones de PHP.

Apache

Timeout 10 Keepalive On ThreadsPerChild 100 MaxKeepAliveRequests 100 KeepAliveTimeout 60 ThreadLimit 100 MaxMemFree 512

Estas son las configuraciones que he ido variado sin lograr exito alguno.

Para darles dimensión del equipo, en este equipo residen todos los web de más de 10 unidades académicas. Lo extraño de esto es que en este momento el equipo no tiene carga ni accesos considerables y la caida del Web se ve por ese lado.

Les copio alguno de los errores:

[Mon Apr 25 17:25:14 2011] [error] [client 68.171.231.20] PHP Fatal error: Out of memory (allocated 1310720) (tried to allocate 98304 bytes) in C:\sitios\Veterinarias\adodb\adodb-time.inc.php on line 1302, referer: https://www.guarani-veterinarias.unlp.edu.ar/a_general/operaciones.php

Pero no siempre ocurre de la misma forma.

Alguien está usando el Pconnect?
Alguno pudo manejar las conexiones con PConnect como si fuera un Pool?
El código de Guarani en ningún momento hace un close de las conexiones. Con PConnect he leido que se cierran cuando se reinicia el Apache o el proceso FastCgi si se utiliza.
Alguno pudo regular las conexiones persistentes, colocando un límite de cantidad?

Estaría bueno utilizar este hilo para que Uds cuenten sus configuraciones, compararlas, hacer la mejor configuración teniendo en cuenta que hay instalaciones muy grandes como la de UNLP.

Todo comentario es bienvenido,

Saludos,
Lic. Alejandro Sabolansky
Responsable de Seguridad
Equipo Guarani - La Plata

2

Hola Alejandro, probaste levantar el memory_limit a 512 o 1 GB ?

3

Hola

Al php lo estás ejecutando como cgi(.exe) o como isapi(.dll)?

Emilio

4

Emilio,

lo estoy ejecutando como cgi.

Con repecto a la otra pregunta el memory_limit no lo subi nunca de 512. Siempre con resultados negativos…

Saludos,
Alejandro

5

Hola Alejandro

Como cgi te carga un php por cada página que llames. Lo cual si hay muchos y/o se torna lento, vas a tener problemas de memoria. Pero son individuales

Como isapi, te cargará la librería y te armará todos los threads. Con ello es mas dificil que tengas problemas de memoria pero entran en juego los parámetros que vos mencionas.

Es una cuestión de tunning. No hay una receta, sino todos la estaríamos usando.

Emilio

6

Emilio, me confundí, era tarde ayer, está con la librería dll , y tiene un solo proceso httpd, no tengo fast-cgi como tenía con IIS , con muchos procesos.

Actualmente tengo la versión de php 5.2.13 estamos probando la 5.2.17 Thread Safe. El tema es que se cae aleatoriamente, ahora se volvió a pinchar, con un error que pierde la conexión a la base, con un getArray() a un objeto vacío.

No hay receta, pero es un problema que me lo tire aleatoriamente…

Seguimos trabajando

Alejandro

7

Estaría bueno la contribución de todos en relación al uso de conexiones persistentes, y los demás temas que he planteado.

Gracias!

Alejandro

8

Ese servidor que tiene mas de 10 unidades academicas se conecta a mas de 10 servidores informix?
No tendrás algun problema de red con alguno de los informix?
No tendrás alguna sobrecarga en el momento que se cuelga?

9

En la Universidad de Córdoba, también hemos tenido problemas en las inscripciones a cursadas por el 3w cuando éstas tienen cupo.
En el momento que surgieron los inconvenientes, teníamos la siguiente configuración:
Servidor WEB: 1 (uno)
S.O:;OpenSUSE 11.1
Apache: 2.2.8
PHP: 5.2.14
Tipo de Conexión: PDO (estamos probando algunos sitios con ODBC y otros cor Driver Nativo)
RAM: 32GB
Procesadores: 16

Servidores de Base de Datos: 12 (doce)
S.O:;OpenSUSE 11.1
INFORMIX: 11.10.FC2
RAM: algunos 4GB y otros 8GB
Procesadores: 8

Ahora tenemos versiones mas nuevas pero no están probadas con el tema del cupo, igual no creo que el upgrade solo lo solucione, además hemos configurado algunos sitios para que usen driver nativo y otros para ODBC, aún no están probados en inscripciones masivas.

En el servidor web tenemos en producción los sitios de las todas la Unidades Académicas de la UNC, esto incluye a los sitios de posgrados. Para grado tenemos 21 sitios y para posgrados 16 sitios.
Pero esto no es problema en el uso diario, el problema es cuando una facultad abre sus inscripciones con cupo, en ese caso, pasamos el resto de los sitios a otro servidor de manera de aislarlo del resto. Igual el problema persiste.

Hemos probado cambiando los parámetros del apache, php e informix con muchas combinaciones distintas, sin embargo no encontramos la solución.
Probamos con conexiones persistentes y no-persistentes, ésta última funcionó mejor, ya que la primera consumía RAM y nunca la liberaba hasta saturar el servidor.
Los principales parámetros con los que probábamos fueron:

APACHE: server-tuning.conf

    ServerLimit 1500
    MaxClients 1500
    MaxRequestsPerChild  15       # este valor quedó luego de muchas pruebas

MaxRequestsPerChild 10000

KeepAlive Off
#KeepAlive On #Consumía RAM y no la liberaba

INFORMIX:
#NETTYPE ipcshm,4,90,CPU # Configure poll thread(s) for nettype
#NETTYPE soctcp,4,90,NET # Configure poll thread(s) for nettype
NETTYPE ipcshm,7,500,CPU # Configure poll thread(s) for nettype
NETTYPE soctcp,7,500,NET # Configure poll thread(s) for nettype

El valor de NETTYPE, fue probado con muchos valores pero las peticiones de conexión por parte del web nunca llegaban a tantas
Esto veíamos en los momentos picos:
Las conexiones ESTABLISHED por el lado del apache al puerto 1525 (informix) estaban alrededor de 260. Si hacía la consulta desde el motor informix, las conexiones del usuario internet no superaban las 90 (cuando según los parámetros del NETTYPE podía ser superior)
Algo a tener en cuenta: En un momento, cambiamos el DNS para que apuntara al servidor de contingencias (que es el web que usábamos anteriormente y da los mismos problemas). Sucedió que como algunos proveedores de internet (ej ARNET) no actualizan sus mapas inmediatamente, éstos clientes seguían buscando en la IP del servidor anterior, y otros con la IP del de contingencias, por los que teníamos 2 servidores web que hacian las inscripciones en un mismo servidor de Base de Datos, en ese contexto, informix subió la cantidad de conexiones de 90 a 180 aprox.
Ante esto, se probó con un balanceador de cargas que enviara automáticamente las peticiones a uno u otro servidor web, pero en este caso se saturaba el balanceador y fue peor.
Cabe aclarar que el motor informix, no reportó que tuviera peticiones sin responder, ni que estuviera saturado, por gestión el comportamiento era normal, sin demoras, el motor informix respondía rápido.

Ahora estamos preparando un servidor para la aplicación SIU-Quecha para ver si al menos quienes puedan ingresar al sitio, puedan completar sus inscripciones en un tiempo razonable

Bueno, esta fue nuestra experiencia en inscripciones con cupo, se nos hace difícil generar pruebas de estrés que simulen esta situación como para poder continuar probando otros medios.

10

Hola Narda

Cual es el problema que ven?

Emilio

11

hola:

Te paso la configuración que tenemos en apache y php, y la memoria no se nos dispara, espero que te sirva. Estamos con:

S.O. Windows 2000 Server SP4
RAM 2 GB
CPU Intel(R) Xeon(R) E5405 Núcleo Cuádruple 2.00GHz
Sw Virtualización Proxmox – KVM
Versión del Guarani 2.6.2
Apache HTTP Server 2.2.17
Versión del PHP 5,2,14

12

El motivo por el cual escribí casi un testamento fue compartir lo que nos pasaba ante inscripciones masivas con cupo, como respuesta a la propuesta de Alejandro de utilizar este hilo para compartir configuraciones, compararlas y en nuestro caso buscar solución a la saturación que ocurre en nuestro servidor WEB en inscripciones con cupo. Esta saturación consiste en que muy pocos usuarios pueden lograr su inscripción tardando muchísimo tiempo, lo que genera caos en las Facultades.
Nosotros no usamos conexiones persistentes porque notamos (como lo dije en el escrito anterior) que nos consumía RAM y nunca la liberaba.
Gracias Alejandro por el aporte y por los archivos de configuración, en general, la diferencia significativa entre lo que enviaste y lo nuestro es justamente la configuración de las conexiones persistentes.
Me queda la duda de cuando decis: “Esto solucionó en forma inmediata el problema del acceso al web en particular para inscripciones masivas con cupo”, ustedes tenían el problema de saturación como nosotros y cambiando la función a pconnect() se solucionó???
Probaremos la función pconnect(), con conexiones persistentes, luego contaremos como nos fue, aunque lograr una simulación de las inscripciones es bastante difícil.
Otra pregunta para Alejandro es que tipo de conectividad usan: PDO,ODBC o Driver Nativo???

Narda

13

Hola Narda

Como es el manejo de las LRU en ifx11?
Ante tanta carga de inscripciones y conteos sobre la comisión no estará trabajando con ese tipo de información?

Tienen una base de datos previa a la ultima inscripcion por cupos?
O sea, se podría generar un testeo de stress basado en las inscripciones anteriores?
Cuando son las proximas inscripciones de este tipo?

14

que tal? queria preguntar en que quedo esto? gracias