como siempre estoy en grandes ligas y no trabajo con pedacitos..
el owncloud y el nextcloud en donde estoy no solo es distribuido (varias servidores por oficina) sino que LOS ARCHIVOS SON EN LOTES GIGANTESCOS Y PEQUEÑOS, en un entorno como este, competir contra "SMB" o samba o "los compartidos" como lo llaman los ignorantes es imposible sin tunear el owncloud..
El problema: owncloud antes de la version 10 (X) falla y degrada su rendimeinto en grandes cantidades masivas para archivos pequeños cuando se usa mysql o sqlite( y nextcloud). La solucion facil e inicial es USAR POSTGRES, sep, hay que usar algo bueno pero lastimosamente no es facil ni rapido si subcontratas gente, te saldra costoso pues no todos usan una base de datos de calidad como postgres..
aqui coloco que se le debe hacer a la basura de mysql o mariadb para que ande mejor, ya que tiene un terrible bug que degrada el rendimiento cuando owncloud o netxcloud tiene que sincronizar archivos
1) Desactivar BINARY LOG ya que la replicacion es un asco
notaran los archvios en /var/log/mysql/ estos son usados para replicaicon mas que todo, y cuando mysql/mariadb explota, recupera las tablas.
desabilitarlo mejora el rendimiento terriblemente, ojo, el mensaje "Checking for corrupt not cleany .." etc etc ya sera solo una pantalla...
entrar en /etc/mysql/my.cnf y comentar las lineas de binary log asi:
nano /etc/my.cnf
encontrar la lieneas sigueintes y colocar "#" adelante de la linea completa asi:
#log_bin = /var/log/mysql/mariadb-bin.log
#expire_logs_days = 10
#max_binlog_size = 100M
despues reiniciar el servicio
service mysql restart
2) TIempo de respuesta en intranets a cero sin el DNS resolve
Mariadb/Mysql pregunta por nombres de dominio al dns de turno de la conexcion activa, para asi poder determinar quien accede o no de la tabla de permisos de accesos a base de datos, y depues de esto lo hace es con las direcciones ip, si usamos una intranet, solo usaremos ip ya que lso servidores tendran y se conectaran por VPN (hayq ue ser imbecil para conectarlos por internet)
Esto tarda casi 20 segundos, que es mucho, se reduce a 0 si desabilitamos y solo usamos direcciones ip asi:
nano /etc/my.cnf
en la seccion "mysqld" adicionar despues de "tmpdir" esta linea asi:
skip-name-resolve
despues reiniciar el servicio
service mysql restart
3) MySQL / MariaDB “READ COMMITED” transaction isolation level
Como he dicho hemos desabilitado el binary log, y esto es porque ownclud usa un modo especial de el mysql o mejor dicho su propio modo de log interno para desastres, estoporque no emplea solo mysql/mariadb, sino postgres y en el caso de nextloud oracle.
nextcloud/ownCloud aisla las transacciones para su traza, esto requiere configurar mysql/mariadb el TRANSACTION_READ_COMMITTED para evitar la pérdida de datos en escenarios de carga elevada (por ejemplo, mediante el uso del cliente de sincronización con muchos clientes / usuarios y muchas operaciones paralelas).
muchas operaciones paralelas = millones de archivos al mismo tiempo
esto se realiza en el archivo de configuracion my.cnf asi:
nano /etc/my.cnf
en la seccion "mysqld" adicionar despues de "tmpdir" o "skip-name-resolve" esta linea asi:
transaction-isolation = READ-COMMITTED
despues reiniciar el servicio
service mysql restart
4) escritura tardia en logs con no uso de I/O
esto no esta documentado, es un truco solo funcional en mi versin especifica de cambios de mi paquete, ya que en interent solo afecta los logs..
en los linuxes comunes de uds esto permitira rendimiento pero OJO SI SE LES APAGA ABRUBTAMENTE perderan alguna informacion, en servidores calidad o usando mis paquetes no habra peligro, esto es porque el corte abrubto no tiene escritura en los los de prediccion de las operaciones en el momento que ocurre el problema..
esto se realiza en el archivo de configuracion my.cnf asi:
nano /etc/my.cnf
en la seccion "mysqld" adicionar despues de "tmpdir" o "skip-name-resolve" esta linea asi:
innodb_flush_log_at_trx_commit = 2
despues reiniciar el servicio
service mysql restart
5) esto es opcional y no muy necesario, pero hay un articulo que realmente es una modificacion del de mysql, en percona, percona es la version "alta disponibilidad" de mysql, es decir algo que si le llega alas patas a postgres, el articulo es este:
Los que tengan plata o los que juegen con juguetes o hardware de verdad, reciomeindo leer:
como un ejemplo de implementacion NAS, pero OJO implementar NAS es especifico de cada hardware NAS.
esto es todo, eso mejora el rendimiento de mysql/mariadb para ekl owncloud, tanto asi que desde OC 9 es la configuracion exigida incluso para nextcloud
Lenz McKAY Gerardo (PICCORO)