Artículos de opinión, videos de humor, música, tecnología, cosas extrañas, críticas, trailers de películas y ocio en general
domingo, 20 de febrero de 2011
sábado, 19 de febrero de 2011
Gore en facebook
En la página del ejército egipcio hay una imagen bastante gore...
Ojito que es bastante dura
update: he tenido que borrar la imagen por ser demasiado dura para alojarla en el éste blog.
En fin, al menos algo podréis ver si seguís éste enlace
https://www.google.es/search?hl=es&q=gore+en+facebook&um=1&ie=UTF-8&tbm=isch&source=og&sa=N&tab=wi
Ojito que es bastante dura
update: he tenido que borrar la imagen por ser demasiado dura para alojarla en el éste blog.
En fin, al menos algo podréis ver si seguís éste enlace
https://www.google.es/search?hl=es&q=gore+en+facebook&um=1&ie=UTF-8&tbm=isch&source=og&sa=N&tab=wi
viernes, 18 de febrero de 2011
Discusión sobre InnoDB Flush - MySQL
El parámetro de configuración innodb_flush_method puede tomar los valores O_DSYNC y O_DIRECT.
Es importante tunear la BBDD, y uno de los parámetros clave es innodb_buffer_pool_size, el cual debe rondar entre el 50% y el 80% de la RAM del sistema.
Leí en un post sobre performance de MySQL que explicaba que en algunos casos, era conveniente evitar el doble cacheo (uno por parte de MySQL y otro por parte del S.O).
Para evitar el cacheo del S.O, se puede especificar el método de flush como O_DIRECT, el cual dice al Kernel que haga el DMA directamente evitando overhead de cacheo.
Pero leyendo un artículo del mismísimo Linus Torvalds, no se si es buena idea realizar éste tipo de tuning. Supongo que dependerá de cada caso. Aquí lo dejo.
A thread on the lkml began with a query about using O_DIRECT when opening a file. An early white paper written by Andrea Arcangeli [interview] to describe the O_DIRECT patch before it was merged into the 2.4 kernel explains, "with O_DIRECT the kernel will do DMA directly from/to the physical memory pointed [to] by the userspace buffer passed as [a] parameter to the read/write syscalls. So there will be no CPU and memory bandwidth spent in the copies between userspace memory and kernel cache, and there will be no CPU time spent in kernel in the management of the cache (like cache lookups, per-page locks etc..)." Linux creator Linus Torvalds was quick to reply that despite all the claims there is no good reason for mounting files with O_DIRECT, suggesting that interfaces like madvise() and posix_fadvise() should be used instead, "there really is no valid reason for EVER using O_DIRECT. You need a buffer whatever IO you do, and it might as well be the page cache. There are better ways to control the page cache than play games and think that a page cache isn't necessary."
Linus went on to explain, "the only reason O_DIRECT exists is because database people are too used to it, because other OS's haven't had enough taste to tell them to do it right, so they've historically hacked their OS to get out of the way. As a result, our madvise and/or posix_fadvise interfaces may not be all that strong, because people sadly don't use them that much. It's a sad example of a totally broken interface (O_DIRECT) resulting in better interfaces not getting used, and then not getting as much development effort put into them."
Es importante tunear la BBDD, y uno de los parámetros clave es innodb_buffer_pool_size, el cual debe rondar entre el 50% y el 80% de la RAM del sistema.
Leí en un post sobre performance de MySQL que explicaba que en algunos casos, era conveniente evitar el doble cacheo (uno por parte de MySQL y otro por parte del S.O).
Para evitar el cacheo del S.O, se puede especificar el método de flush como O_DIRECT, el cual dice al Kernel que haga el DMA directamente evitando overhead de cacheo.
Pero leyendo un artículo del mismísimo Linus Torvalds, no se si es buena idea realizar éste tipo de tuning. Supongo que dependerá de cada caso. Aquí lo dejo.
A thread on the lkml began with a query about using O_DIRECT when opening a file. An early white paper written by Andrea Arcangeli [interview] to describe the O_DIRECT patch before it was merged into the 2.4 kernel explains, "with O_DIRECT the kernel will do DMA directly from/to the physical memory pointed [to] by the userspace buffer passed as [a] parameter to the read/write syscalls. So there will be no CPU and memory bandwidth spent in the copies between userspace memory and kernel cache, and there will be no CPU time spent in kernel in the management of the cache (like cache lookups, per-page locks etc..)." Linux creator Linus Torvalds was quick to reply that despite all the claims there is no good reason for mounting files with O_DIRECT, suggesting that interfaces like madvise() and posix_fadvise() should be used instead, "there really is no valid reason for EVER using O_DIRECT. You need a buffer whatever IO you do, and it might as well be the page cache. There are better ways to control the page cache than play games and think that a page cache isn't necessary."
Linus went on to explain, "the only reason O_DIRECT exists is because database people are too used to it, because other OS's haven't had enough taste to tell them to do it right, so they've historically hacked their OS to get out of the way. As a result, our madvise and/or posix_fadvise interfaces may not be all that strong, because people sadly don't use them that much. It's a sad example of a totally broken interface (O_DIRECT) resulting in better interfaces not getting used, and then not getting as much development effort put into them."
Etiquetas:
database,
innodb,
mysql,
o_direct,
programación
miércoles, 9 de febrero de 2011
miércoles, 2 de febrero de 2011
Sphinx 1.10-beta en Ubuntu 10
Ésta guia me ha permitido configurar y realizar requests a sphinx 1.10-beta desde php con apache2, mysql5 y php5.3.
El paquete no es estable, y por ello no viene incluido en el repositorio de ubuntu. Lo que aquí he probado no sería la opción más recomendable para producción dado que aún tiene bugs.
Ojo que aquí omito la creacion de la BBDD en MySQL y la creacion del index (sudo indexer index1, que hay que configurarlo previamente). Todo eso podeis encontrarlo googleando un poco.
http://sphinxsearch.com/docs/1.10/
sudo apt-get install libmysqlclient-dev (los headers de mysql actualizados, ya que mysql-dev está obsoleto)
CXXCPP="gcc -E" ./configure --prefix=/usr/local/sphinx (--with-mysql-includes es opcional si quieres especificar donde esta mysql)
sudo make
sudo make install
-- compilar la api/libsphinxclient
cd sphinxFolder/api/libsphinxclient/
sudo make install
-- si peta, corregir el bug en el sphinxclient.c (esperemos lo corrijan en la proxima version)
#ifndef _WIN32
if ( setsockopt ( sock, SOL_SOCKET, SO_NOSIGPIPE, (void *)&optval,
(socklen_t)sizeof(optval)
{
set_error ( client, "setsockopt() failed: %s", sock_error() );
return -1;
}
#endif
->
#ifndef _WIN32
#ifdef SO_NOSIGPIPE
if ( setsockopt ( sock, SOL_SOCKET, SO_NOSIGPIPE, (void *)&optval,
(socklen_t)sizeof(optval)
{
set_error ( client, "setsockopt() failed: %s", sock_error() );
return -1;
}
#endif
#endif
#define vsnprintf _vsnprintf
->
//#define vsnprintf _vsnprintf
-- ejecutar
/api/libsphinxclient/test -z 'usr/local/sphinx/include' o sino -> mkdir -p -- "/usr/local/sphinx/include"
sudo pecl install sphinx (especificar path /usr/local/sphinx)
-- añadir a php.ini
"extension=sphinx.so"
El paquete no es estable, y por ello no viene incluido en el repositorio de ubuntu. Lo que aquí he probado no sería la opción más recomendable para producción dado que aún tiene bugs.
Ojo que aquí omito la creacion de la BBDD en MySQL y la creacion del index (sudo indexer index1, que hay que configurarlo previamente). Todo eso podeis encontrarlo googleando un poco.
http://sphinxsearch.com/docs/1.10/
sudo apt-get install libmysqlclient-dev (los headers de mysql actualizados, ya que mysql-dev está obsoleto)
CXXCPP="gcc -E" ./configure --prefix=/usr/local/sphinx (--with-mysql-includes es opcional si quieres especificar donde esta mysql)
sudo make
sudo make install
-- compilar la api/libsphinxclient
cd sphinxFolder/api/libsphinxclient/
sudo make install
-- si peta, corregir el bug en el sphinxclient.c (esperemos lo corrijan en la proxima version)
#ifndef _WIN32
if ( setsockopt ( sock, SOL_SOCKET, SO_NOSIGPIPE, (void *)&optval,
(socklen_t)sizeof(optval)
{
set_error ( client, "setsockopt() failed: %s", sock_error() );
return -1;
}
#endif
->
#ifndef _WIN32
#ifdef SO_NOSIGPIPE
if ( setsockopt ( sock, SOL_SOCKET, SO_NOSIGPIPE, (void *)&optval,
(socklen_t)sizeof(optval)
{
set_error ( client, "setsockopt() failed: %s", sock_error() );
return -1;
}
#endif
#endif
#define vsnprintf _vsnprintf
->
//#define vsnprintf _vsnprintf
-- ejecutar
/api/libsphinxclient/test -z 'usr/local/sphinx/include' o sino -> mkdir -p -- "/usr/local/sphinx/include"
sudo pecl install sphinx (especificar path /usr/local/sphinx)
-- añadir a php.ini
"extension=sphinx.so"
Suscribirse a:
Entradas (Atom)