configuration Archives - tech.feub.net

MySQL/MariaDB : Déterminer la taille recommandée de innodb_buffer_pool_size

Rapide mémo pour déterminer la taille recommandée du buffer pour les tables utilisant le moteur de stockage InnoDB de MySQL. Par défaut après installation cette valeur est en général à 128 Mo, ce qui peut être bien bas pour de grosses bases de données.

La requête ci-dessous retourne la taille à renseigner pour la valeur de la variable innodb_buffer_pool_size :

SELECT 
	CEILING(Total_InnoDB_Bytes*1.6/POWER(1024,3)) RIBPS 
FROM (
	SELECT 
		SUM(data_length+index_length) Total_InnoDB_Bytes
	FROM information_schema.tables 
	WHERE engine='InnoDB'
) A;

Il suffit alors de renseigner cette valeur dans le fichier de configuration /etc/my.cnf :

[mysqld]
innodb_buffer_pool_size=8G

Redémarrer MySQL/MariaDB :

$ sudo systemctl restart mariadb

Installer et utiliser l’analyseur de fichiers de log Logwatch sur CentOS 7

Recevoir des rapports système clairs et concis avec l’anayseur de logs Logwatch sous CentOS 7.

L’analyse des fichiers de log d’un serveur peut se révéler fastidieuse et difficile suivant le nombre et la complexité de services qui tournent sur une machine. C’est sur ce point que l’outil Logwatch peut aider l’administrateur système, en effet celui-ci rassemble différents fichiers de logs et les affiche de façon claire, sous la forme d’un rapport plus lisible que les fichiers bruts.

Logwatch n’est pas vraiment un outil destiné par exemple à lire les logs après un problème afin d’en trouver la cause, car en général une analyse plus poussée et ciblée doit être effectuée dans un tel cas, mais il est plus particulièrement utile pour faire du reporting sur l’état d’une machine à un moment donné. Par exemple l’utilisation classique qui est celle par défaut en général est d’avoir le rapport de la journée de la veille envoyée par email.

Ma configuration Nginx

Les pages de ce site sont désormais servies par Nginx depuis quelques semaines, et j’en suis totalement ravi. Au début il y a eu une période d’incertitude et de petite frayeur du au fait de basculer d’Apache que je maitrise relativement bien, vers une plateforme toute nouvelle avec d’autres habitudes à prendre, d’autres conventions, un style différent (mais pas tant que ça). D’ailleurs en parlant de petite frayeur, avant-hier les sites hébergés sur le Kimsufi ont été indisponibles durant environ 4 heures, j’ai bataillé et sué fort pour trouver mon erreur, ma foi comme souvent, un peu bête ^(*).

Ce billet fait un peu le point sur ma configuration actuelle de Nginx. J’ai essayé de la faire le plus modulaire possible en créant des blocs relatifs à certains environnements qui sont ou non inclus dans les server blocks (le nom des virtual hosts chez Nginx). Par exemple, j’ai un morceau de code pour les spécificités de WordPress, de Koken ou pour ajouter la gestion HTTPS (SSL).

Configuration

Avec Fedora, la configuration de Nginx se situe sous /etc/nginx, j’y ai créé 2 autres répertoires /etc/nginx/global et /etc/nginx/vhosts. Dans le premier je place tous les blocs de code possiblement redondants – ceux cités plus haut – et dans le second sont placés tous les server blocks, personnellement je crée un fichier par domaine, par exemple j’ai /etc/nginx/vhosts/feub.net.conf pour feub.net.
Le fichier lu par Nginx est /etc/nginx/nginx.conf, je ne l’ai pour ainsi dire pas touché, j’ai juste ajouté un include vers mon répertoire de vhosts, prenant en compte les fichiers se terminant par .conf uniquement :

include /etc/nginx/vhosts/*.conf;

Et voici un exemple de fichier de configuration pour le domaine feub.net :

server {
	listen          80;
	server_name     www.feub.net;
	
	rewrite ^(.*) 	http://feub.net$1 permanent;
}

server {
	listen          80;
	server_name     feub.net;

	root            /var/www/websites_root/feub.net/www/html;
	index           index.php index.html index.htm;

	access_log      /var/log/nginx/feub.net.access.log;
	error_log       /var/log/nginx/feub.net.error.log;

	location / {
		try_files 	$uri $uri/ /index.php?$args;
	}

	include global/php.conf;
	include global/wordpress.conf;
	include global/things_not_logged.conf;
}

Ma nouvelle configuration Ivy Bridge

Il y a un peu plus de 7 ans, j’étais l’heureux switcher vers le monde d’OS X. Toujours enthousiaste à l’évocation d’Apple, j’en ai tout de même perdu la fascination et je dois l’avouer après une longue période entre deux eaux, ne sachant pas où placer mon pied, j’ai mentalement franchi le pas et je me tourne vers le PC.

Pourquoi ce virement? Plusieurs choses, qui ne font pas vraiment partie de ce billet, mais pour rapidement évoquer quelques points, je dirais qu’il y a en particulier l’iOSisation trop prononcée d’OS X qui ne me plait pas – alors que des éléments comme le Finder restent pré-historiques dans leurs fonctions – Apple oublie de plus en plus les power users et je crois et j’ai peur que cela ne va que s’accentuer. Le coté hardware également fait très peur avec les processeurs et maintenant la RAM qui sont soudés à la carte mère sur de nombreux modèles, aucune possibilité d’évolution.
Ce sont grosso-modo les 2 gros points qui me gênent s’il y en avait à dire à propos d’Apple, mais ce virement n’est pas totalement du à mon mécontentement d’Apple, il est surtout du à l’envie et l’excitation de revenir aux joies de choisir ce que l’on veut dans son boitier, de revenir à des possibilités de modularité énormes et là je dois dire que je me suis fait un petit plaisir, presque une cure de jouvence émotiono-tech ^.^