29M Huelga general

opinionLa primera huelga general que me pilló trabajando fue la de diciembre de 1988 en protesta contra la reforma laboral de Felipe González. Tenía 20 años y trabajaba en los almacenes de un centro comercial de la cadena Carrefour (que por aquellos entonces se llamaba Continente). Cuando le manifesté mi deseo de secundar la huelga al jefe de mi sección me dijo, casi textualmente, “Tú estás en tu derecho de hacer la huelga y yo en el mío de solicitar a personal que no te renueven el contrato. Y te cumple el mes que viene. No te digo más.” Me la envainé, como suele decirse, y el día de la huelga fui a trabajar. Estaba en primero de carrera, no tenía ningún tipo de cualificación y sin ese trabajo, o uno similar, no podía permitirme seguir estudiando. Cuando llegué a mi centro de trabajo hubiera agradecido enormemente que hubiera allí un piquete que impidiera el acceso o que me permitiera poner la excusa de que no pude entrar por miedo a que me agredieran. Pero no, no hubo piquete y tuve que cumplir con mi jornada contra mi voluntad.

A todos los que salen estos días con eso de que “también hay que respetar el derecho al trabajo” les pediría que tuvieran en cuenta que esta presión por parte de las empresas existe aunque ellos hayan tenido la suerte de no experimentarla nunca (o miren para otro lado cuando ocurre a su lado), y que esta otra forma de violencia es silenciosa y no se percibe de forma tan evidente. Mientras exista, la única forma de pelear contra ella es mediante piquetes. Ojalá no fueran necesarios.

Dudas y reflexiones sobre el modelo de Formación Profesional Dual

educación Uno de los planteamientos “estrella” del nuevo Ministerio de Educación es la implantación en nuestro país de un modelo de Formación Profesional Dual en el que el estudiante reparte su tiempo de formación entre un centro de estudios y otro de trabajo y percibe por ello un salario. Durante las últimas semanas he leído bastante acerca de este sistema y, aunque le reconozco ciertas ventajas, le veo serios inconvenientes y soy escéptico en cuanto a la posibilidad real de trasladarlo a nuestro país más que, quizás, de forma testimonial y muy reducida. Yo estudié formación profesional según el antiguo modelo de los 80 y desde hace unos años doy clases en la nueva modalidad de ciclos formativos (así que algo conozco el sistema) pero lo que viene a continuación no pretende ser más que una serie de reflexiones en voz alta sobre lo que pienso. Al final y a modo de referencia tienes una lista de enlaces a algunos de los textos, artículos y otras referencias de apoyo que he estado leyendo para que te formes una opinión por ti mismo.

Este modelo de FP se imparte en varios países europeos pero es en Alemania donde tiene una mayor implantación y tradición y por eso se lo publicita como FP Dual Alemana. Su regulación por ley se hizo allí en el año 1969 y en la actualidad “sólo” alcanza al 50% del total de matriculados de Formación Profesional. Está orientada sobre todo a las titulaciones relacionadas con los sectores industrial y de comercio y tiene escasa o nula presencia en titulaciones de otros sectores como sanidad, educación o servicios sociales. En los últimos años está experimentando cierto retroceso y cada vez son menos los estudiantes que pueden optar por este modelo y más los que se incorporan a la Formación Profesional reglada muy similar a la de nuestro país con un periodo de prácticas al final de los estudios. Puede que se trate de algo coyuntural a causa de la crisis pero, en ese caso, no parece ser un buen momento para incorporarlo a nuestro sistema educativo.

La implantación de este modelo de FP ya se ha probado con anterioridad en Euskadi, la comunidad autónoma que realiza una mayor inversión por alumno de nuestro país y los resultados no han sido positivos. De hecho, allí se piensa que el modelo no es trasladable.

Los estudiantes que optan a este modelo de FP no se matriculan en un centro educativo, sino que envían su solicitud a una de las empresas participantes que es la que realiza la selección de candidatos. Por un lado parece lógico que la empresa que les va a contratar y a sufragar una parte importante del coste de su formación participe en este proceso de selección, pero también es preocupante que no se va a tratar de un sistema universal y que muchos candidatos podrían quedar excluidos en este primer filtro y por motivos que pueden ser dudosos y cuestionables (sexo, raza, edad, etc.) cosa que nunca jamás debería de ocurrir con un sistema educativo público.

Las empresas que quieran participar en este sistema precisan de una infraestructura apropiada con empleados específicos que trabajen como formadores dentro de su plantilla y que deben de haber superado unas pruebas de idoneidad. Esto supone una inversión importante a sumar al coste que les supone contratar a los alumnos (sueldo, cotización, impuestos, etc.). En Alemania los estudiantes reciben entre 500 y 800 euros al mes según la región, el sector y el año de estudio. Puesto que en Alemania el salario medio es el doble que en nuestro país (allí no existe el salario mínimo así que no podemos comparar este parámetro), aquí podríamos esperar sueldos de entre 250 y 400 euros al mes. Allí el coste para la empresa por alumno y curso es de aproximadamente 18.000€. Pongamos que aquí pudiera hacerse por la mitad. Sabiendo que el coste mínimo por contratar a un empleado en España pagándole el salario mínimo ronda los 11.000€ y conociendo las circunstancias actuales, resulta evidente que a una empresa le resultaría mucho más cómodo y rentable a corto plazo contratar a alguien ya formado y por un coste muy similar.

En España en los años 80 ya se barajó la introducción de este modelo de formación y se descartó porque las empresas no estaban dispuestas a asumir estos costes. De hecho, el modelo español de formación profesional que se imparte en la actualidad y que incluye un trimestre de prácticas al final de los dos años, cuando el alumno ya está formado, se realiza de forma que el alumno no cobra y a la empresa no sólo no le cuesta nada sino que se la recompensa económicamente. Aún así, en algunos sectores a veces es bastante difícil encontrar empresas dispuestas a hacerse cargo de este trimestre de prácticas. Si esto es así con nuestro modelo actual ¿aceptarán nuestras empresas pagar costes de esta magnitud por admitir a alguien sin ningún tipo de formación?

Supongamos por un momento un modelo alternativo para adaptar el sistema a nuestra realidad en el que se subvencione fuertemente a las empresas en lugar de hacerlas partícipes de los gastos. En este caso se corre un grave riesgo de fraude. La empresa tiene durante tres años a alguien que está cobrando un sueldo aunque no haga nada y por quién percibe dinero y/o bonificaciones fiscales de algún tipo. También podrían aprovecharse para contratar durante tres años a alguien sin necesidad de formación y subvencionado por el estado. Que esto no es Alemania, no nos engañemos…

La formación en este modelo se reparte de forma que el alumno asiste uno o dos días al centro de estudios y tres o cuatro a la empresa. Es decir, entre el 60% y el 80% de su formación estará fuertemente orientada a lo que se haga en esa empresa en particular y no necesariamente al trabajo común del sector profesional de su especialidad ¿Estará ese profesional en condiciones de encontrar trabajo en otra empresa diferente de la que lo formó, si lo necesita? ¿En un momento en el que se nos pide que no pensemos en un trabajo para toda la vida es lógico introducir un cambio en el sistema educativo que pretende formarnos como si así lo fuera?

Lecturas y referencias:

ACTUALIZACIÓN: Amadeo Mora, uno de los responsables del piloto de FP dual que se está haciendo este año en la Comunidad de Madrid en el IES Clara del Rey para el ciclo de Desarrollo de Aplicaciones Multiplataforma (DAM), dio el otro día una charla en Toledo y han dejado aquí el material usado en las mismas. Así veis otra opinión de alguién que conoce de primera mano la adaptación que se trata de hacer a nuestro país y que tiene una visión mucho más positiva que la mía de su futuro.

ACTUALIZACIÓN (y II): El informe que recientemente ha publicado ADIMAD (Asociación de Directores de Institutos de Educación de Secundaria de Madrid) coincide en gran parte con las reflexiones que aquí he planteado.

ACTUALIZACIÓN (y III): Experiencia de primera mano de un alumno de segundo año de la primera promoción de DAM (Desarrollo de Aplicaciones Multiplataforma) de la primera promoción de FP Dual en el IES Clara del Rey.

ACTUALIZACIÓN (y IV): Me he enterado recientemente de otro motivo de preocupación sobre la forma en que se está implantando este modelo en nuestro país. Si la empresa decide suspender el contrato con el alumno en cualquiera de los dos años que dura su formación, el centro educativo se ve en la necesidad de expulsarlo sin ningún tipo de titulación o alternativa. Suena mal ¿verdad? En el curso pasado (2013-14), sin embargo viví en primera persona un caso en que la empresa decidió expulsar a un alumno después de su primer año y el centro donde estudiaba decidió “reubicarlo” en el segundo año del mismo ciclo en su modalidad presencial. Algo insólito puesto que los planes de estudios son muy diferentes y el alumno en cuestión no entraba en igualdad de condiciones con sus compañeros. No se cual de ambas soluciones es peor, la verdad…

ACTUALIZACIÓN (y V): Otra opinión de alguien que parece conocer bastante bien este sistema desde dentro.

Apache Tunning. Ajustando recursos en un servidor web con poca memoria

apacheInstalar un servidor Apache en un entorno Linux debe de ser lo más fácil del mundo. Configurarlo para que funcione de forma aceptable sirviendo una o dos instancias web también es sencillo. Ajustarlo para que funcione de forma eficiente en entornos escasos de recursos o para que escale bien ante grandes cargas ya es algo en lo que muy pocos se meten. Si siempre has trabajado con servidores compartidos no te habrás dado cuenta de esto último porque alguien te lo ha dado ya hecho. Pero tanto si has tenido que gestionar servidores propios y/o dedicados o pequeños VPS posiblemente hayas tenido algún problema en este sentido. Y si no, creeme: los vas a tener…

La forma en que Apache gestiona la multitarea a la hora de atender a los clientes del servidor web se configura mediante los módulos MPM. Los dos más comúnmente usados son Prefork y Worker pero existe por ahí alguno más. Al instalar apache2 en Debian (y en todas las distribuciones, me atrevería a decir) se instala por defecto el paquete apache2-mpm-prefork y este es el módulo MPM que funcionará por defecto. Para probar con worker basta con instalarlo (apt-get install apache2-mpm-worker en una Debian) y automáticamente desinstalará el otro mpm (sólo puede haber uno en cada momento) y reiniciará el servicio de apache para que los cambios tomen efecto.

La primera pregunta que se nos plantea es, lógicamente, cual elegir. A grandes rasgos la principal diferencia entre ambos es que Prefork crea siempre nuevos procesos para gestionar las conexiones entrantes mientras que con Worker los procesos hijos, a su vez, crean múltiples hebras cada uno de ellos para esta tarea. Tienes información más precisa de como funcionan en los enlaces de hace unas líneas. Prefork tiene a gala ser más estable y funcionar mejor en máquinas escasas de recursos, mientras que Worker presume de ser más escalable y eficiente para servidores más ambiciosos. Para novatos o instalaciones sin necesidades especiales es mejor quedarse con la opción por defecto (Prefork) puesto que, además, incluso algo tan simple como instalar PHP es trivial y habitual con este módulo mientras que hay que “enredar” bastante más para hacerlo funcionar con Worker.

Si el servidor no lo hemos instalado nosotros y queremos saber que MPM está activo basta con recordar que sólo puede haber uno, así que podemos mirar que paquete está instalado (aptitude search apache2-mpm-* en Debian, de nuevo) o interrogar directamente a apache con la opción -l:

root@invernalia:/etc/apache2# apache2 -l
Compiled in modules:
  core.c
  mod_log_config.c
  mod_logio.c
  prefork.c
  http_core.c
  mod_so.c

Pero independientemente del módulo que escojamos, el comportamiento final del servidor web será muy parecido. Pensemos que se trata de un servicio diseñado para atender múltiples peticiones simultaneas de decenas (o centenares, si tenemos una web con éxito) de clientes y hacerlo de forma eficiente y en el menor tiempo posible. Nuestro servidor permanecerá a la espera de estas peticiones y, cuando vayan llegando, destinará a un proceso (o a una hebra de un proceso) a atenderlas. Cuantos más peticiones se cursen de forma simultanea, más procesos/hebras necesitaremos y consumiremos más recursos de la máquina. Sobre todo memoria. Un servidor web se comporta como un insaciable devorador de RAM. Este va a ser el recurso que debemos de aprender a gestionar: la RAM que no se usa cuando se necesita se desperdicia y nos hace perder visitantes o que estos sean atendidos más lentamente. Pero si no controlamos el consumo y el servidor la agota comenzará a hacer swapping a disco y evitar esto es la regla de oro: Si llegamos a este punto lo habremos perdido y, posiblemente, tendrás que reiniciar el servicio (o la máquina, si no tienes tiempo o paciencia) para volver a tomar el control.

Los principales ajustes que necesitamos hacer se encuentran en nueve líneas del archivo /etc/apache2/apache2.conf. A continuación tienes los valores por defecto en una instalación básica de Debian 6: Ten cuidado porque las cinco últimas se encontraran duplicadas en el interior de sentencias condicionales segun el módulo MPM que estemos usando. Las que nos interesan hoy son las que están tras la sentencia <IfModule mpm_prefork_module>.

Timeout 		300
KeepAlive 		On
MaxKeepAliveRequests	100
KeepAliveTimeout   	15
StartServers        	5
MinSpareServers     	5
MaxSpareServers     	10
MaxClients		150
MaxRequestsPerChild	0

Timeout, el primero de ellos, define el tiempo en segundos que Apache esperará a determinados eventos antes de cerrar o abortar una conexión. En servidores con pocos recursos 300 segundos puede ser una cantidad bastante elevada. Reducir ese tiempo sustancialmente ayudará a gestionar mejor la memoria del servidor. Valores de 30 o 40 son adecuados en servidores con pocos recursos. Un valor de 10, incluso, podría mejorar el rendimiento en determinados entornos.

Los tres parámetros siguientes (KeepAlive, MaxKeepAliveRequest y KeepAliveTimeout) definen la posibilidad de usar conexiones persistentes y la forma de tratarlas. En concreto, el número de peticiones que se permitirán sobre cada conexión (MaxKeepAliveRequest) y el tiempo de espera sin peticiones antes de abortarlas. Tener habilitadas este tipo de conexiones reduce sustancialmente la carga del servidor y los tiempos de respuesta y el número de peticiones se puede mantener en torno a 100 en casi cualquier entorno. Es, de nuevo, el Timeout por defecto de 15 segundos el que puede resultar demasiado elevado en servidores con poca RAM y podríamos reducirlo a un valor de 5 segundos o incluso menos.

Los cinco parámetros restantes son los que definen el comportamiento del módulo Prefork. StartServers, MinSpareServers y MaxSpareServers ajustan, respectivamente, el número de procesos apache que se crearan inicialmente, y el mínimo y máximo de estos que mantendremos inactivos a la espera de que lleguen peticiones de posibles clientes. Los procesos inactivos definidos por estos parámetros estarán consumiendo memoria pero nos permitirán dar una respuesta más rápida a los clientes (los procesos están ya listos para usarse cuando llegan peticiones y no hay que perder tiempo en crearlos), así que en un servidor con grandes recursos y que espera cargas elevadas querríamos tener valores más elevados de los que vienen por defecto mientras que en un servidor pequeño podríamos reducirlos todos a, por ejemplo, 3 o 4.

MaxClients es, posiblemente, el parámetro más importante. Define el máximo número de procesos simultaneos que nuestro servidor podrá crear para atender peticiones. Un número más pequeño del que podemos permitirnos desperdiciará memoria y ralentizará las peticiones de muchos clientes (que permanecerán a la espera de que uno de estos procesos se libere para atenderle) mientras que un número demasiado elevado agotará la memoria del servidor y lo obligará a hacer swapping a disco. Y aquí no hay fórmulas mágicas. Lo primero que se nos puede ocurrir es que dividiendo la memoria que tenemos disponible entre lo que ocupa cada proceso de Apache obtendríamos el número que necesitamos, pero el problema es que la memoria disponible es difícil de calcular de forma exacta (ya que, posiblemente, tendremos también un servidor mysql, servicios de correo, etc). Además, los procesos de apache no consumen todos la misma cantidad de memoria. Si tenemos distintas instancias de apache con características muy diferentes la diversidad será aún mayor. Podemos verlo en el siguiente pantallazo de htop tomado de un servidor apache funcionando con varias instancias web diferentes:
Vista de htop en un servidor apache que estamos monitorizando

La columna MEM% nos da el porcentaje de memoria que está ocupando el proceso de apache y, como vemos, tenemos cifras entre 0.5% y 4.2%, es decir, entre 4 y 32 Mbytes (la máquina es un VPS con 768Mbytes). Si aproximamos que disponemos de 600Mbytes disponibles para que apache los use nos saldrían cifras de entre 150 y 18 procesos simultaneos. Una horquilla demasiado grande. Si somos muy, muy conservadores podemos irnos al borde inferior de la horquilla y asegurar que nunca entraremos en zona de riesgo. Podemos también dedicarle tiempo a estudiar el comportamiento medio de nuestros clientes y hacer medias de la utilización de memoria por los procesos de Apache. Lo más rápido para empezar es tomar un valor medio, por ejemplo de un 2.5% o un 3% y ajustar por ahí el número máximo de procesos. Entre 25 y 40 en este caso. El hecho de que hayamos bajado mucho los Timeouts ayudará a que los procesos se liberen rápidamente y se turnen atendiendo a los clientes que están a la espera con lo que no deberíamos de notar demasiado la espera.

Tenemos aún otro parámetro más. MaxRequestsPerChild marca el número de peticiones que atenderá cada proceso antes de reciclarse. El valor por defecto es cero que indica un número indefinido. Poner un número elevado pero no ilimitado ayudará también a que nuestro servidor libere y sanee su memoria de forma regular. Un valor de entre 500 o 1000 podría ser adecuado para nuestra pequeña máquina. Nuestra configuración final podría quedar así:

Timeout 		10
KeepAlive 		On
MaxKeepAliveRequests	100
KeepAliveTimeout   	5
StartServers        	3
MinSpareServers     	3
MaxSpareServers     	4
MaxClients		30
MaxRequestsPerChild	600

No olvides que hay que reiniciar el servicio de apache (service apache2 restart) después de realizar cualquier modificación en este fichero de configuración para que los cambios tomen efecto.

AWStats Total

estadisticas Es lo último que escribo sobre esto y ya dejo de daros la lata sobre este “antiguedad”. AWStats Total es un script PHP que te permite ver de un vistazo un resumen de todas las instancias web, servidores de correo, etc. cuyas estadísticas estamos controlando. El aspecto que presenta, una vez instalado, es así:

Pantallazo de AWstats-total

Ponerlo a funcionar en un servidor donde ya tenemos AWstats funcionando es muy sencillo. Basta con crear una instancia web para esto (o usar un directorio en la instancia por defecto), copiar en ella el archivo awstatstotal.php que podemos descargarnos de la página del proyecto y configurar adecuadamente la seccion de configuración de dicho script para que se adecue a nuestra instalación. Si hemos configurado AWStats tal y como hemos visto en el primer texto de esta serie la configuración del script sería así:

$DirData = '/var/lib/awstats';
$AWStatsURL = '/awstats/awstats.pl';
$Lang = 'es';
$DirLang = '/usr/local/awstats/wwwroot/cgi-bin/lang';
$NotViewed = 'columns';
$sort_default = 'unique';