Busco SYSADMIN CPANEL

Buenas,

Tengo un servidor dedicado, y tengo un problema, la particion /VAR se me esta llenando y me da errores de MYSQL continuamente hasta que borro algunos logs y hago espacio.

El tema es que he leido muchos tutoriales sobre mover la carpeta /VAR/LIB/MYSQL al directorio HOME y crear enlaces simbolicos, pero siempre que he probado nunca me ha funcionado.

Asi que necesito algun sysadmin que me ayude a realizarlo y pagarle el tiempo que utilice.

Alguna empresa o sysadmin de confianza?

gracias

 

neocomp en este foro puede echarte una mano por $$

 

¿Antes de hacer eso has activado el log rotate para evitar que se te llene la partición /var? Te lo comento por que si haces eso y no tienes activado el log rotate te va a seguir pasando lo mismo por más espacio que le des al /var.

http://docs.cpanel.net/twiki/bin/view/AllDocumentation/WHMDocs/LogRotate

Pregunta en https://www.copernico.net/es/contactar

 

PD: La partición no la tienes que mover al home si no claro que no te funciona. Simplemente activa log rotate y amplia espacio si ves que te hace falta.

 

Gracias por la recomendación vicram , hace un par de horas recibí un contacto directo en mis Blackberrys y a los pocos segundos ya estabamos contactando a fasti, primero hice un diagnóstico general de las características del servidor y luego me fuí a la parte "interesante" ... ver que tal estaba MySQL y como sucede en más del 90% de los servidores que he revisado había "serios" problemas con la configuración de MySQL.

Solo por mencionar 2 problemas extremadamente críticos :

InnoDB no tenía asignada la suficiente cantidad de memoria para manejar las tablas InnoDB, lo cual es MUY complicado porque "se supone" que el 100% de las tablas InnoDB deben quedar almacenadas en RAM

Se estaban generando más de 4 tablas temporales a disco "por segundo" ... supongo que no necesito comentar mucho al respecto, pero se pueden imaginar todo el tráfico de IO y consumo de cpu que implica estar permanentemente accesando con escrituras a disco.

En MySQL es crítico optimizar el uso de RAM habilitando los caches adecuados con el fin de reducir al máximo los accesos a disco, además conviene utilizar un sistema de discos con RAID 10 "obviamente" con controladora RAID y no por software e "idealmente" un sistema con discos SSD.

En 10 minutos ya está lista la primera optimización y cada unas 3 horas van a seguir las siguientes ya que se necesitan las estadísticas de uso y que como lo he comentado en reiteradas ocasiones, la optimización de MySQL depende de los recursos disponibles y del uso que tienen los distintos tipos de tablas y por lo general las configuraciones encontradas en Google no sirven de mucho, lamentablemente tienen que ser hechas "a la medida" de cada servidor y sistema.

Mas adelante seguiremos aportando con mas tips de optimización de MySQL

 

Todo lo que dices esta bastante bien, aunque por lo que leo arriba el usuario tiene problemas de espacio, lo cual no es referente a la configuración o no ?

 

Hay un particionamiento bastante "raro" y hay un serio problema de archivos que se generaban en la partición donde se encuentran los archivos de MySQL que saturaban la particion y "obviamente" bloqueaban MySQL ... el problema es que si tienes un MySQL muy mal configurado y que está generando "miles" de archivos en disco para poder almacenar las tablas temporales y un InnoDB que necesita casi 1 Gb de RAM que no está asignada y que "supongo" que tambien comienza a generar archivos temporales ( no he investigado más sobre que hace InnoDB cuando no tiene la suficiente RAM ... pero ya lo haré ), entonces el responsable de ocupar "súbitamente" el espacio disponible debe haber sido el mismo MySQL ... de hecho después de las primeras optimizaciones el espacio disponible se ha mantenido estable y no se ha seguido generando esa cantidad impresionante de archivos a disco ( más de 27.000 tablas temporales a disco por hora ).

Se llegaron a ocupar más de 1,5 Gb de disco en un par de horas ... eso es muy difícil que sea por culpa de los archivos de logs.

Cuando tenga más info puedo agregar comentarios mas específicos, ya que primero hay que "apagar el incendio" y luego seguir investigando un poco más a fondo sobre los orígenes del problema.

 

En cPanel 1.5 gigas en logs no es nada, hace poco me han contactado por este mismo problema y he eliminado hasta 36 gigas en logs.

300 megas del cron.
3 gigas del doomlogs.
y 30 gigas de un nginx mal configurado.
Y el resto en otros logs.

Lo de particionado raro ummm será un servidor de OVH estándar varios teras para /home y 20 gb para / lo cual tiene un problema, /var/log, los logs de apache en /usr/local, y mysql lo llenan bastante rápido.

El tema de que mysql crea tablas temporales por mal configuración, pues si, pero hay otro tema, estructuras mal creadas, bases de datos mal desarrolladas las cuales no guardan nada en RAM y se va todo a disco duro por mejor configuración que tengas ya que las queryes son un desastre.

Lo de innodb y la RAM tiene varios asuntos, si tienes un innodb de 8 gigas tendrás que asignar un poco más de RAM que eso, pero si no tienes ram no pasa nada si no lo asignas. El tema es que no tiene que estar en memoria, o sea que mysql no hace un dumb del innodb cuando inicia y lo guarda en ram, si no que lo usa de cache, así que podemos suponer que tienes un innodb de 8 gigas de peso pero que no usas para nada o muy poco, no te harán falta 8 gigas de ram ya que ejecutas pocas queryes ( ej 200 mb ) así que con 1 giga puedes ir más que sobrado ya que solo ocuparas el espacio para cachear, pero si, ira mejor siempre ira mejor si asignas a innodb más RAM de la que pesan las tablas.

 

Completamente de acuerdo en que encontrar varios Gigas en logs de cPanel no es algo raro, pero en servidores que han estado funcionando por varios meses e incluso años ... no en UN PAR DE HORAS.

Correcto estaba en OVH ... no estoy acostumbrado a usar cosas en OVH así que ese particionamiento era nuevo para mí
Asi que una recomendación para los que compren servidores en OVH ... tratar de configurar con otras capacidades las particiones que ellos usan por defecto, porque 20 Gb es bastante poco para una partición donde van los logs y sobre todo MySQL.

Creo que si analizamos a fondo cualquier servidor MySQL, en casi el 100% vamos a encontrar estructuras mal creadas ... la mayoría de los programadores no tienen mucha idea de estructuras de datos y mucho menos de estructuración y optimización de índices ... muchos no saben que SOLO usando una buena estructura de tablas, un tipo de tabla adecuado y un muy buen sistema de índices el acceso a la misma tabla se puede acelerar cientos o incluso miles de veces usando exactamente el mismo hardware.
Si tienes casi cualquier servidor MySQL que este generando más de 4 tablas temporales a disco POR SEGUNDO, va a producir un tremendo problema de rendimiento ... si a eso le agregas que hay "RAID por software" y discos SATA el problema es aún mas grave.
Con las primeras optimizaciones la cantidad de queries lentas ya se redujo 36 veces y la cantidad de tablas temporales a disco también ya se redujo verias veces ... ahora el servidor esta "respirando" un poco.

Aca habia casi 30.000 tablas y más del 50% eran InnoDB por lo mismo la importancia de asignar mas RAM a InnoDB pasa a ser "muy importante" ya que la cantidad de queries era bastante alta.
La RAM asignada era menos del 10% del total necesario para todas las tablas InnoDB
Por lo mismo la GRAN ventaja que tenemos hoy de usar discos SSD al menos para los servidores MySQL.

Como también encontré peaks que usaban hasta 100% de todos los cores, ya están preparando un nuevo servidor de acuerdo a mis sugerencias duplicando la cantidad de cores, cuadruplicando RAM y lo más importante con tarjeta controladora RAID en vez de "RAID por software" ... además obviamente de usar otro esquema de particionamiento de disco ... ahora viene la parte "entretenida" de la migración jejejejejejejejeej.

 

Se me olvidaba ... una alternativa híbrida que ya está disponible con algunos proveedores es servidores con 2 discos SATA + 2 discos SSD con controladora RAID, asi se podría instalar MySQL en discos SSD.

Personalmente no uso nada que no tenga como mínimo RAID-10 y por lo tanto al menos 4 discos, si a eso le sumamos discos SAS 15K o SSD aun mejor ... aunque mas caro "obviamente".

 

Vamos al cotilleo, ¿cuanto le vas a cobrar? xDDD

Estas preguntas son las que me gustan porque son las que hacen los clientes, le explicas todo, no entienden nada, y después de una magnifica presentación dicen. ¿cuanto me cuesta? OJO no preguntan cuantas horas, si es dificil o si lo puedes hacer dentro de una semana, NO. Para ayer y barato!!

La verdad que hoy en día encontrar un Sysadmin decente es jodido... Por tanto, si su trabajo y precio es bueno, no cambies.

 

jejejejeje ... la pregunta del millón, pero no tengo problemas en comentar al respecto ... en este caso voy a cobrar US$ 100

El gran problema para determinar un costo respecto a un análisis y optimización de un servidor MySQL es que es difícil determinar de antemano la complejidad del problema ya que la mayoría de las veces hay involucrados problemas de rendimiento derivados de la mala calidad del hardware o la falta de recursos del servidor que no tienen que ver directamente con la optimización o configuración de MySQL.

Los casos mas complejos son cuando ya hay una optimización y el hardware es "aceptable" y hay que entrar a analizar los archivos de logs de MySQL para resolver problemas de tablas mal estructuradas y sobre todo falta de índices o índices mal configurados.

Normalmente solicito el acceso root antes de entregar cualquier presupuesto para hacerme una idea general de "como está la cosa" sin modificar nada, ya que muchas veces el cliente no tiene ni siquiera claro cuales son las características técnicas del servidor, pero un análisis y optimización de MySQL normalmente está en el rango de los US$ 50 a US$ 150 ... las ventajas que yo ofrezco es que no solo hago la optimización sino que un análisis muy detallado de rendimiento general del servidor, sugerencias respecto a optimizaciones de hardware, hardening, etc, etc ... además obviamente de todos los problemas detectados y si son solucionables o no con el equipo actual ... otro punto es que no solamente se incluye "una" optimización sino que usualmente son varias optimizaciones en un período de varios días, ya que para poder evaluar que tal anda un servidor MySQL son imprescindibles las estadísticas de uso por al menos unas 48 horas.

Otro punto sería que puedo permanecer online por Skype todo el tiempo que sea necesario e ir comentando en el mismo minuto con el cliente los problemas que voy detectando, creo que casi siempre cobro precios "muy razonables" y normalmente puedo resolver las cosas "para ayer" ... con tantos años de circo me bastan un par de minutos para hacer un análisis detallado de un servidor MySQL y un cliente me puede contactar en segundos desde mi página directo a los Blackberrys.

Respecto al punto de la "decencia" que me parece muy válido e importante, puedo comentar que estudié Ingeniería en Informática, tengo además unas 10.000 horas de experiencia dictando clases relacionadas con el área informática, incluyendo por ejemplo asignaturas como Técnicas de Programación, Bases de Datos o Estructura de Datos y muuuuuuuuuchos años desarrollando e implementando sistemas bajo PHP + MySQL ( además de varios más bajo dBase, FoxBase, Clipper, Paradox, Access, etc y otros tanto en la prehistoria usando "hasta" Cobol jejejejejeje ) ... todo eso además de unos 15 años administrando servidores web y varios clusters de servidores 24 x 7 x 365.

Y si por a, b o c no logro determinar el problema o no puedo demostrar "con números" verificables por el cliente una mejora real de rendimiento, no hay problema en reintegrar hasta el 100% de lo cobrado ... hasta el minuto afortunadamente NUNCA ha pasado eso

También está la opción de hacer convenios por análisis y optimización de servidores en forma permanente con algunas empresas, asi les sale aún mas económico ... y muchas veces también he hecho recomendaciones "sin costo" cuando por ejemplo no hay mucho más que hacer, hace un par de semanas alguien quería hacer una optimización de MySQL en un VPS con cPanel que solo tenía 1 core, 1 disco SATA y 512 Mb de RAM ... si ya estaba ocupada casi toda la RAM no queda mucho para optimizar