Sistemas operativos

Debian logo

Cambiando todo el hardware del ordenador en Debian 7 Wheezy

0

Después de unos cuantos años sin renovar el hardware del pc, este mes tocó renovación, y a lo grande. Principalmente por el final de soporte de Windows XP y que para algunos proyectos (y juegos… ejem, ejem) necesitaba más memoria RAM.

He dedicado bastantes horas a valorar que hardware comprar y que no se me fuese de presupuesto. Al final me decidí por lo siguiente:

Micro AMD FX 8350 Black Edition (8 nucleos)

Placa base ASUS M5A99FX PRO R2.0

Tarjeta gráfica ASUS GeForce NVIDIA GTX 780

– Fuente de alimentación Aerocool Strike-X 800

Y torre nueva: Aerocool Strike-X Advance

Los discos duros, aunque ya han superado su edad de vida media, aun funcionan, así que de momento no se tocan.

La instalación fue relativamente sencilla, aunque como ocurre siempre en un equipo de hace seis años, siempre hay algo que no funciona en el hardware nuevo. Uno de ellos fue uno de los discos duros, que por alguna extraña razón la placa no me lo reconocía. Por suerte solo era un disco para almacenar chorradillas que no se donde meterlas.

Una vez conectados los discos duros y que todo estuviera bien conectado, crucé los dedos y pulse el interruptor de la torre… se encendió a la primera, la placa base, los leds azules de la la torre, los ventiladores, el cooler, la gráfica, los discos duros,… espera… ¿Y ese pantallazo azul?… Mierda, Windows XP ha cascao, seguro que tenía alguna librería en el disco duro que no reconocía la placa, en fin, ¡Larga vida a Debian 7!

La verdad es que no fue un gran problema que Windows XP muriese en el proceso, al fin y al cabo llevaba tiempo queriendo cambiar definitivamente a Debian, así que fue una razón más para abandonar Windows por algo mucho mejor.

Aunque leí que cambiar el hardware en Debian no tenía por qué suponer un problema, es decir, que al entrar en el Sistema Operativo todo funcionaría igual; mi experiencia me decía que esto iba a cascar por todos lados.

Bueno pues me equivoqué a medias: el cambio de hardware hizo que se mostrasen algunos fallos (el módulo del kernel para la tarjeta de red, por ejemplo), pero solo fallo por un lado: la tarjeta gráfica, que impedía que se iniciase el servidor gráfico.

Y es que Debian 7 Wheezy no reconocía la gráfica debido a que los drivers de nvidia en Wheezy solo llegan hasta la 302, y para que me la reconociese necesitaba mínimo la 319, que es la que da soporte a la GTX 780.

¿Solución? Actualizar a Debian 8 Jessie, o lo que es lo mismo: pasar de stable a testing. He de decir que Jessie es bastante estable, y sabiendo que está previsto que se congele la inclusión de nuevos paquetes en esta rama hacia Noviembre de 2014, no había riesgo de que fallase por otro lado.

En primer lugar hay que editar el archivo /etc/apt/sources.list y sustituir la palabra “wheezy” por “jessie“, y “stable” por “testing“.

Hacemos un apt-get update, y si todo ha ido bien ejecutamos apt-get dist-upgrade, y a esperar que se descargue e instale todo.

Una vez instalado todo, seguiremos sin gráfica y sin servidor gráfico. Primero comprobamos que ahora sí reconoce la gráfica escribiendo en la consola el siguiente comando: lspci | grep “VGA”.

Este comando nos debe mostrar el modelo de tarjeta gráfica que tenemos.

Y a partir de aquí es hora de configurar la gráfica. Para ello os voy a dejar un artículo que me ha ayudado muchísimo a la hora de configurarla y se merece que le enlace; los pasos a seguir ya sea en Debian 7 Wheezy o Debian 8 Jessie son los mismos, con lo que espero que este tutorial os valga tanto como me ha servido a mí:

Instalar los drivers nvidia privativos en Debian

Abrir carpeta desde cmd

0

Algo muy habitual que hacemos con la consola, ya se en Windows, Linux o MacOS es recorrer directorios en busca de algún archivo. Aquí te explicaré como poder hacerlo.

Si lo que buscas es poder abrir una ventana de MS-DOS desde el explorador de Windows, te recomiendo el siguiente post: ¿Cómo abro una ventana de MS-DOS desde una carpeta?

 

En Windows:

Para desplazarnos por los directorios o carpetas en la consola de Windows utilizamos el comando “cd” seguido por la ruta de la carpeta a la que queramos acceder. Por ejemplo, si queremos acceder a la carpeta Windows escribiríamos el siguiente comando en la consola:

 

cd c:/windows

 

Si el nombre de la carpeta tiene espacios podemos utilizar la barra invertida (\) para indicarle a la terminal que el espacio en blanco siguiente es parte del nombre del directorio. Por ejemplo:

 

cd c:/Archivos\ de\ Programa

 

En Linux y MacOS:

MacOs tiene un kernel GNU/Linux y por tanto estas instrucciones sirven igual. Para acceder a una carpeta utilizaríamos en mismo comando “cd”. Ejemplo:

 

cd /var

 

Si el nombre del directorio tiene espacios utilizaremos el mismo sistema para escapar el espacio en blanco del nombre:

 

cd /tmp/carpeta\ nueva

Scrapy: Framework en Phyton para obtener datos de la web (Instalación en Debian)

0

Desde hace unos años se viene produciendo una necesidad por recopilar la mayor cantidad de datos posible, procesarlos y analizarlos. Las herramientas comprendidas dentro del llamado Big Data permiten esto, aunque hay un pequeño sector que está creciendo en importancia: la obtención de datos desde otras web. No estoy hablando de APIs, sino de recopilar información del html que nos exponen otras páginas webs.

A la recopilación de esta información se le llama Web Scraping (http://es.wikipedia.org/wiki/Web_scraping), y está comprendido dentro de las técnicas de Minería de Datos (http://es.wikipedia.org/wiki/Miner%C3%ADa_de_datos) del Big Data (http://es.wikipedia.org/wiki/Big_data).

Scrapy nos permite realizar esta tarea de la forma más cómoda posible, aunque necesitarás conocimientos de Phyton para poder usarla.

En Debian su instalación es muy sencilla.

Primero es necesario asegurarnos que disponemos de las librerías adecuadas:

apt-get install phyton phyton-dev phyton-pip libxml2-dev libxslt-dev libffi-dev

En segundo lugar, instalamos Scrapy:

pip install scrapy

Una vez finalizado el proceso de instalación nos vamos al directorio donde tengamos nuestros proyectos de programación, y allí ejecutamos la siguiente línea en la consola:

scrapy startproject nombre_proyecto

Este comando nos creará el directorio del proyecto (nombre_proyecto) y todo el árbol de directorios y archivos necesarios para empezar.

Gnulinux

Crear un tunel por SSH por consola (GNU/Linux)

0

Pues la verdad es que es bastante sencillo:

ssh -L 2022:servidordestino.com:22 usuario@servidorintermedio.com

Con este comando indicamos que ssh nos cree una conexión por el puerto 2022 de nuestro equipo al puerto 22 de servidordestino.com, a través de servidorintermedio.com.

Después solo hay que escribir el siguiente comando:

ssh -l usuario -p 2022 localhost

Esta línea indica a ssh que nos abra una conexión ssh por el puerto 2022 de localhost (nuestro ordenador). Esta conexión nos llevará a servidordestino.com que hemos indicado en el primer comando.

ubuntu logo

Añadir un tiempo de espera al menú de reparación de GRUB

0

Dispongo de un servidor de integración continua para mis proyectos y otras cosillas, el cual no tiene ningún periférico de entrada (teclado), con lo que me conecto a él a través de ssh, como $deity manda.

Sin embargo, el cabroncete, a veces entra en modo de solo lectura y me toca reiniciar. Esto provoca que salte el menú de reparación de grub, que en Ubuntu 12.04 (desconozco si lo hace en el resto de versiones) no tiene un contador para arrancar automáticamente con la primera opción del menú. Hoy he solucionado precisamente eso.

GRUB dispone de un archivo de configuración en /boot/grub/grub.cfg.

Buscamos el siguiente condicional:

terminal_output gfxterm
if [ "${recordfail}" = 1 ]; then
set timeout=-1
else
set timeout=2
fi

Bien, ese “-1″ es el que deberemos sustituir. Así que editaremos el archivo /etc/default/grub, donde se encuentran las variables por defecto de GRUB. Añadimos la siguiente variable:

GRUB_RECORDFAIL_TIMEOUT=10

Guardamos (recuerda que debes editar el archivo como root) y ejecutamos el siguiente comando (también como root) que generará el archivo de configuración de GRUB con los cambios ya realizados.

update-grub2

Y listo. Podéis verificar que el cambio se ha realizado visualizando el archivo /boot/grub/grub.cfg.

Así el cabroncete se iniciará de forma automática. Y no tendréis que estar conectándole un teclado y un monitor para ver que le pasa (a no ser que sea algo peor).

 

Debian logo

Discos duros en RAID en Debian

0

Os dejo un tutorial muy interesante y que he utilizado para configurar varios discos duros en RAID 1:

 

http://www.howtoforge.com/how-to-set-up-software-raid1-on-a-running-system-incl-grub2-configuration-debian-squeeze

¿Cómo abro una ventana de MS-DOS desde una carpeta concreta?

1

Esa es la pregunta que, cada vez que tenía que usar los comandos de MS-DOS me venía a la mente, y supongo que a muchos de vosotros también os haya pasado. Pues bien, hoy tengo una solución para esa pregunta que todo usuario se ha hecho alguna vez:

  1. Abrimos el editor del registro de Windows. (regedit.exe)
  2. Buscamos la siguiente carpeta: HKEY_CLASSES_ROOT\Directory\shell
  3. Aquí creamos una clave (os creará una carpeta nueva) y la llamamos por ejemplo “Consola”
  4. Asegurate de estar en la carpeta “Consola”. A la derecha, debajo de la columna “Nombre” te aparecerá este texto: “(Predeterminado)”, pulsa ocn el botón derecho del ratón encima del texto y pulsa modificar.
  5. En la ventana que te aparezca escribe como valor: “Abrir un terminal de MS-DOS aquí”. Este será el texto que aparecerá en nuestro menú contextual.
  6. Crea otra clave (otra carpeta) llamada “command” y dale el siguiente valor: “cmd.exe /k “cd %L”” (cd %L debe ir entre comillas dobles).
  7. Cierra RegEdit. Ve a cualquer carpeta y con el cursor sobre ella pulsa el botón derecho, te aparecerá el texto que acabamos de incluir en el registro y si lo pulsas se abrirá una consola de MS-DOS con la ubicación de esa carpeta.

Vía: http://yatocaba.wordpress.com/2009/05/01/truco-windows-abrir-terminal-en-una-carpeta-concreta/

Optimización de WordPress

Instalar Eaccelerator y Zend Optimizer en Plesk y CentOS

25

Fin de semana entretenido además de atareado. Y por fin puedo decir que he conseguido instalar Eaccelerator y Zend Optimizer en el VPS.

Después de asegurarme de que todo ha funcionado correctamente, os escribo este post con la pequeña odisea.

Instalar yum

En el último post que escribí os conté que no fui capaz de instalar nada debido a que el comando yum no estaba disponible en el VPS. Bien pues vamos al tema:

Para los que no lo sepais, el comando yum es el “clon” del comando apt-get de las distribuciones basadas en Debian; yum es el comando para las distribuciones RedHat, y CentOS es una de estas. Ambos comandos sirven para instalar, desinstalar, actualizar (tanto programas como la misma distribución), etc.

Para poder usar el comando yum es necesario instalar un paquete para Plesk. Los comandos necesarios son los siguientes:

wget -q -O – http://www.atomicorp.com/installers/atomic |sh

Una vez instalado ya podremos usar el comando yum perfectamente. Así que… ¡Hala! A actualizar el servidor:

yum upgrade

PHP

Para poder instalar Eaccelerator es necesario disponer de PHP 5.x, comprueba tu versión a través del siguiente comando:

php -v

Podeis probar a actualizar la versión de vuestro PHP si veis que no es la actual:

yum update php

Instalar Eaccelerator

Para poder instalar Eaccelerator necesitas varios paquetes que deben estar instalados en tu servidor:

PHP 5, autoconf, automake, libtool y m4

Una vez comprobado que tienes estos paquetes instalados procede a descargar Eaccelerator:

wget http://bart.eaccelerator.net/source/0.9.6.1/eaccelerator-0.9.6.1.zip

Descomprimimos:

unzip eaccelerator-0.9.6.1.zip

Accedemos a la carpeta que se ha creado:

cd eaccelerator-0.9.6.1

Y ejecutamos los siguientes comandos:

phpize
./configure
make
make install

Con estos comandos Eaccelerator se instalará y solo nos quedaría reiniciar Apache:

/etc/init.d/httpd restart

O bien:

service httpd restart

Una vez reiniciado Apache debería mostrarnos, en la versión de php, que Eaccelerator está instalado:

php -v

nos debería mostrar algo como esto:

PHP 5.2.13 (cli) (built: Jun 2 2010 16:29:01)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
with eAccelerator v0.9.6.1, Copyright (c) 2004-2010 eAccelerator, by eAccelerator
with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend Technologies

Zend Optimizer

Con Eaccelerator se consigue que el consumo de memoria se reduzca considerablemente, pero aun se puede reducir más. Para ello instalaremos Zend Optimizer en nuestro servidor.

Esta aplicación es mucho más fácil de instalar que la anterior:

cd /usr/local/src
wget http://www.eth0.us/files/ZendOptimizer-3.3.9-linux-glibc23-x86_64.tar.gz
tar -zxf ZendOptimizer-3.3.9-linux-glibc23-x86_64.tar.gz
cd ZendOptimizer-3.3.9-linux-glibc23-x86_64
./install

Ya está. Reinicia Apache como he indicado anteriormente y comprueba, en la versión de php, que Zend Optimizer está instalado correctamente.

WordPress

Para los que hayais llegado hasta este post buscando como optimizar WordPress, os diré que con estas dos aplicaciones se puede reducir el consumo de memoría a una cuarta parte de lo habitual. Así se ha quedado mi WordPress después de instalar Eaccelerator y Zend Optimizer:

Consumo de memoría después de instalar Eaccelerator y Zend Optimizer

WordPress pasó de consumir 41,79 MB a 11,7 MB (72% de reducción).

Optimización de WordPress

Mi última pesadilla: Optimizar el VPS para WordPress

16

Pesadilla… de tres semanas y pico. Anoche soñé con la lista de procesos del comando top de Linux. Apache consumía cada vez más y más memoría. Por consumir, consumió el Kernel de Linux y se transformó en el Kernel de Windows. Y no se porqué antes de despertarme entre sudores fríos apareció Bill Gates descojonandose a moco tendido. Dios, ¡Qué imagen!, no se me quita de la cabeza.

Durante este tiempo me he didicado a “intentar” optimizar tanto el VPS como WordPress para reducir el consumo de memoría. Aunque he hecho algunas mejoras (pocas por desgracia) sigue cayendose Apache; pero comenzaré por el prinicpio:

¿Porqué un VPS?

  1. Por el precio: Ví un VPS más o menos al mismo precio que un hosting y apliqué el dicho “burro grande ande o no ande”.
  2. Por aprendizaje: Nunca había probado un VPS y quería saber como poder administrarlo, que se puede hacer con él. No jodes tantas cosas como con un dedicado y hasta cierto punto tienes menos responsabilidad y es mucho más barato. Y es el paso lógico antes de administrar un dedicado, en el que ahí estas solo completamente.
  3. Por unificar mis proyectos web: Dispongo de cinco dominios. Para cada uno tengo planes para crear una web con ellos,o en algunos casos ya está creada y online, en otro, estoy esperando a ver que pasa con el VPS y otros solo estan proyectados. Disponer de todas las webs en un solo servidor, ya que no tienen muchas visitas, es muy pero que muy cómodo, además de económico.
  4. Por ahorar costes: Cinco dominios, cinco hostings. Aunque los hay muy baratos (desde un euro) siempre te limitan alguna cosa y no me convencian.
  5. Por libertad: La posibilidad de hacer y deshacer a mi antojo, en definitiva, de tener el control de la máquina (virtual) es una gozada.

Características del VPS

  • Memoría RAM: 256 MB
  • Espacio en disco: 5 GB
  • Transferencia mensual: 150 GB
  • Sistema operativo: CentOS 5
  • Panel de control: Plesk
  • Y obviamente el resto de características habituales: Perl, PHP, MySQL, etc, etc, etc.

El principio

Cuando contraté este VPS, era un puto ignorante, así de claro, desconocía muchas cosas sobre la administración de servidores, su optimización, y sobre todo, las características que había que observar detenidamente antes de contratar nada (en VPS. En hosting, tengo bastante idea). Menos mal que era el más barato xD.

Desde el tercer o cuarto día comenzó a fallar Apache. Los datos que obtenía tanto de Plesk como de Virtuozzo me indicaban que la memoría se saturaba y paraba los servicios. Claro, como un ignorante creé un ticket al proovedor. La respuesta fué rápida (y ahora la más lógica), “actualice su VPS a uno superior”. No comprendía como me podían decir eso. ¡Que sólo es un blog! ¡Que el día que llega a 100 visitas monto la fiesta padre! !Coño, que no es Digg, ni el Mundo! ¿Cómo podía ser que con solo al acceder a la página principal de la administración (el escritorio de WordPress), Apache ya se viniese abajo? ¿Cómo era posible?.

Sólo había una idea en mi cabeza: “Estos del hosting quieren sacarme más pasta” (Viendolo ahora, en cierto sentido, tenía razón). Pero esa idea no soluciona el problema, aunque mi cabezonería la convirtió en  mantra y como con levantar Apache o reiniciar el contenedor volvía todo a funcionar, se quedo así durante meses.

Primeros intentos

No soy una persona que se rinda fácilmente. Yo siempre digo que en informática no hay nada imposible, sino poco presupuesto. Así que comencé a informarme sobre VPS, WordPress, Apache, etc. De esto puede dar fe mi navegador (uso Opera) que ahora mismo tengo abiertas unas 50 pestañas.

Lo primero fue buscar una forma para averiguar cuánta memoría consumía WordPress. Encontré el siguiente código:

$memoria_usada = round(memory_get_usage(1) / 1024,1);
echo ‘Memoria usada: ‘ . round(memory_get_usage() / 1024,1) . ‘ KB de ‘ . $memoria_usada . ‘ KB';

Este código indica la memoría que había antes de ejcutar el script (que se guarda en la variable $memoria_usada y se pone al inicio del archivo) y la memoría consumida después de ejecutar el script (que se pone al final). Los datos en local que saqué fueron los siguientes:

9 plugins: Memoria usada: 27462 KB de 67.1 KB
Sin plugins: Memoria usada: 20468.8 KB de 67.2 KB
Actualizando el theme: Memoria usada: 21049.1 KB de 67.1 KB (Utilizando el theme que tengo en el blog actualmente, sustituyendo al theme por defecto)

Siento no tener los datos del VPS, pero no varían mucho. Ahora mismo consume 29,5 MB con ocho plugins activos (no son los mismos plugins han variado desde entonces) más el theme.

Las pruebas las realicé con WordPress 3.0.1 con la base de datos tal cual se instala, bajo Windows con la suit de AppServ sin modificaciones.

Yo, cuando ví las cifras, me quedé alucinado: ¡Wordpress consume casi 20,5 MB!. Realicé pruebas con otras versiones de WordPress para verificar que esto era así, es decir, comprobar que con el paso de las versiones el consumo de memoria había aumentado. Que no era cosa mía, sino que es así de chupón. Aunque aquí puede variar el consumo de memoría dependiendo de las reglas de mod_rewrite de Apache, de como esté optimizado PHP y MySQL, etc. El único culpable no es WordPress, pero acojona.

Viendo lo visto, era hora de actuar.

WordPress a dieta

Sabía que existian varios plugins que permitian cachear las páginas del blog y reducir el consumo de memoria y procesador, pero simpre lo había visto en blogs con miles de visitas, no en uno cutre con theme gratuito que no llega a las cien visitas diarias (triste pero cierto).

El primero en activar en el blog, wp-cache, me costó un poco instalarlo, más por mi inexperiencia con cachés que otra cosa (mira que es sencillito el plugin). Al final no se lo que me paso, no lo recuerdo, que lo desactivé. Busqué otro.

WP Super Cache, no mienten los que hablan bien de él, funciona estupendamente, es un poco más complicado de configurar que wp-cache pero el resultado es magnífico. Pero el blog seguía consumiendo casi 30 MB de memoría y Apache se caía. Mejoró la estabilidad del blog un poco, al menos de cara al visitante sí. Pero seguía con el mismo problema: en cuanto entraba en el Escritorio Apache se escoñaba.

Antes de esto probé cada uno de los plugins para ver cual era el que hacía que Apache se cayera nada más entrar en las administración del blog. WordPress.com Stats era el culpable, la establidiad mejoró sustancialmente teniendo este plugin desactivado. Durante unos días pensé que estaba solucionado el problema, nada más lejos de la realidad. Aunque el blog consumia menos memoría, en cuanto hacía algo que requiriese más esfuerzo por parte de la RAM, Apache se venía abajo. Simplemente con entrar varias veces en el escritorio del blog o activar un plugin, Apache caía. Fue frustrante.

Un plugin del que no conocía su existencia es DB Cache Reloaded. Como su nombre indica, permite cachear las consultas a la base de datos, evitando que se conecte a la base de datos cada vez que haya una petición a esta. Reduce el consumo de recursos. Bien. Activado está y funciona de maravilla, aunque de momento no termina de cachear todas las consultas. Tendré que mirar porqué.

Pero el problema continuaba, Apache se caía. Había que entrar en el servidor.

SSH

Tengo que admitir que no me había conectado nunca a otro ordenador a través de SSH, si a través de VNC y VPNs.

Trabajo con Windows XP SP3 principalmente, pero no le hago ascos a las distribuciones linux, todo lo contrarío: en VirtualBox tengo instalados Debian, CentOS, Ubuntu y ChromeOS, y excepto para el tema de configurar la tarjeta gráfica que aun no he conseguido (creo que VirtualBox es el que no la reconoce y por algún motivo envía al SO una tarjeta gráfica compatible con la que tengo, pero me obliga a estar con una resolución de 800×600).

Bien, ¿porqué cuento esto?. Además de por que quería contarselo a alguien xD, por que así comprenderás que después de varios intentos por conectarme al servidor con varios programitas para Windows, arrancase una máquina virtual para conectarme por la consola de linux. ¡Bendita seas!. Hasta que descubrí que lo que me fallaba era el puerto para poder acceder. ¡La ignorancia da la felicidad!.

Una vez conectado al servidor lo primero que hice fue un top de la máquina para conocer el consumo de RAM (la leche no) en tiempo real.

Me indicaba que tenía 512 MB de RAM total y la memoría consumida oscilaba entre los 170 y los 220 MB, aunque en algunos podía llegar a 270 MB. El problema radica en que el VPS no tiene 512 MB de RAM sino 256 MB; los otros 256 es memoría compartida, con lo que no puedo contar con ella para realizar el cálculo.

También hice un free -m para comprobar la memoria, pero top me ofrece más datos.

Observé que cuando se pide al servidor una página apache ejecuta cuatro procesos de sí mismo llegando en varios casos a consumir un 12 por ciento de memoría RAM. Lo normales un 10 por ciento.

A por Apache

Optimizar Apache. Me costó un huevo y medio encontrar la ubicación de los archivos de configuración, pero cuando me enpeño… (/etc/httpd/conf en CentOS). Bien, leí que si realizaba ciertas modificaciónes en el archivo httpd.conf de Apache podría reducir el consumo de memoría. Por defecto la configuración de Apache era la siguiente:

<IfModule prefork.c>
StartServers                     8
MinSpareServers              5
MaxSpareServers            20
ServerLimit                   256
MaxClients                   256
MaxRequestsPerChild   4000
</IfModule>

Se quedo así:

<IfModule prefork.c>
StartServers                      5
MinSpareServers               5
MaxSpareServers             10
ServerLimit                     30
MaxClients                     30
MaxRequestsPerChild 40000
</IfModule>

No solucionó mucho, o por lo menos yo no lo noté. Reduje también varios parámetros más, como el tiempo que espera Apache para cerrar una conexión permanente, etc.

Esto seguía sin mejorar. Probemos con la base de datos

MySQL

Poca optimización realicé aquí, la verdad. Me limite a añadir la configuración para habilitar la caché de la BD, pero no ha hecho mucho. También puede deberse a que el plugin de WordPress que cachea las consultas ya lo está haciendo. No sé. La configuración quedo del siguiente modo:

query_cache_type = 1
query_cache_limit = 1M
query_cache_size = 8M

PHP

Para optimizar PHP necesitaba instalar en el VPS Eaccelerator y el Zend Optimizer, mis pocos intentos me han llevado a pensar que no puedo instalar nada que no sea a través de Plesk o que necesite el comando yum. Por tanto, a día de hoy, PHP está sin optimizar, habrá que enviar un ticket a ver si ellos me lo isntalan…

VPS

CentOS consume memoría, como todos los SO, las veces que he podido ver el consumo de memoría sin Apache, está rondaba entre 60 y 80 MB. Pero no sólo es el sistema operativo el que consume RAM, Plesk también consume lo suyo (unos 50 MB), he deshabilitado el antivirus que me consumía 70 MB cada vez que se iniciaba. Pero aunque el VPS se ha estabilizado hay momentos en los que Apache tiene cuatro procesos abiertos de 50-60 MB cada uno (según el comando top). Excesivo.

Intenté crear un archivo SWAP pero el comando swapon no lo tengo permitido, al menos por SSH.

CONCLUSIONES

  • Sigo valorando distintas opciones respecto a la optimización del VPS, ahora mismo mi mejor baza es Eaccelerator y que me lo instalen en el VPS para reducir la memoría.
  • Seguiré probando con algunnos plugin de WordPress a ver que tal.
  • Si estas interesado en la contratación de un VPS andate con ojo con la RAM.
  • Me he planteado incluso cambiar de VPS o ampliarlo con la misma empresa o marcharme a otra, ya se verá en septiembre.
  • Lo mejor de todo esto: lo aprendido por el camino. No solo conozco un poco mejor los sistemas Linux, sino también Apache, PHP, MySQL y Plesk, y su administración.
  • Bueno, ¿Y vosotros?¿Qué experiencia habeis tenido con los VPS?¿Qué consejos podeis darme? o simplemente ¿Qué opinais? Los comentarios son vuestros… mientras Apache lo permita xD.

LINKS

Os dejo unos links y así libero al navegador de carga, pobre.

Optimización del VPS

Optimización de WordPress

Optimización de PHP

Optimización de Apache

    SSH en Windows con PuTTy

    0

    Para poder conectar con un servidor en remoto, habitualmente se usa SSH. Uno de los mejores programas para Windows (ya que la consola de este sistema operativo no permite este tipo de conexion) es Putty.

    Os dejo el link de descarga y un tutorial que os indicará como cofigurarlo para poder conectar remotamente a un servidor:

    Descargar PuTTy

    Tutorial de PuTTy

    Ir arriba