Ir al contenido

Buscar en La Comunidad

Mostrando resultados por etiquetas 'servicios'.

  • Buscar Por Etiquetas

    Añade etiquetas separadas por comas.
  • Buscar Por Autor

Tipo de Contenido


Foros

  • Contacto con el staff
    • Novedades / Anuncios del foro
    • Sugerencias
    • Problemas relacionados con el foro
  • Zona general de charla
    • Presentaciones
    • Charla
    • Zona de Humor, Curiosidades y Otros
    • Mascotas Vagos
    • Noticias del Mundo
    • Tecnología
    • Ayuda y consultas de carácter general
  • Zona GNU/Linux
    • Ayuda, consultas y soporte GNU/Linux
    • Distribuciones GNU/Linux
    • Repositorios. Software GNU/Linux
    • Personalización
    • Raspberry Pi
    • Arduino
    • Manuales / Tutoriales / Guías GNU/Linux
    • Programación
    • Noticias GNU/Linux
    • Hablando de GNU/Linux
  • Zona Gaming
    • Juegos GNU/Linux
    • Noticias Gamer
    • Charla Gamer
  • Zona Móvil
    • Ayuda y soporte para dispositivos móviles
    • Apps Móviles
    • Manuales / Tutoriales / Guías Móviles
    • Roms para dispositivos Móviles
    • Noticias sobre dispositivos Móviles
    • Hablando sobre dispositivos Móviles
  • Zona Mozilla
    • Ayuda, consultas y soporte Mozilla
    • Aplicaciones Mozilla
    • Roms Firefox OS
    • Manuales / Tutoriales / Guías Mozilla
    • Noticias Mozilla
    • Hablando de Mozilla
  • Microsoft
    • Papelera del Foro

Encontrar resultados en...

Encontrar resutados que...


Fecha de Creación

  • Start

    Fin


Última Actualización

  • Start

    Fin


Filtrar por numero de...

Joined

  • Start

    Fin


Grupo


Página Web


Diaspora


Pump


GNU Social


Google +


Twitter


Facebook


Xmpp


Skype


Steam


Desura


MediaGoblin


Youtube


Vimeo


Picasa


Flickr


Email


Lugar


Intereses

Encontramos 3 resultados

  1. Stacer es un monitor de sistema que a su vez cuenta con funciones de optimización del sistema, tales como gestión de servicios y de aplicaciones se inician durante el ararnque, desinstalación de paquetes, limpiador y monitorización y gestión de procesos, a la vez que muestra información sobre el uso de disco y Ram e información de las transmisiones de red. En su última versión fue rescrito en lenguaje C++, por lo que se ha vuelto un software aún más ligero y versátil cuya interfaz tiene ahora un diseño "responsive". Capturas Descarga Desde el portal de descarga de Stacer podemos obtener los paquetes precompilados de la última versión para Debian y Fedora, ambos para la arquitectura x86_64. También lo encontraremos en formato AppImage https://github.com/oguzhaninan/Stacer/releases Encontraremos también, en Sourceforge, su código fuente y algunos empaquetados https://sourceforge.net/projects/stacer/files/ Compilación Para otras distribuciones o casos, podemos compilar stacer a partir de su código fuente, para lo cual necesitaremos cmake y ninja-build git clone https://github.com/oguzhaninan/Stacer cd Stacer mkdir build && cd build cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH=/qt/path/bin -G Ninja .. ninja output/bin/stacer Web https://github.com/oguzhaninan/Stacer
  2. Entre las ventajas de Systemd, implantado ya en algunas distribuciones y a punto de serlo en muchas otras, es la posibilidad de analizar y optimizar el arranque mediante las propias herramientas del propio systemd. Analizando el arranque Las órdenes que utilizaremos para realizar los análisis son todas las relacionadas con: systemd-analyze time Como ven, es bastante obvia su función y es fácil de recordar. De hecho, si no especificáramos nada, por defecto se ejecutaría la orden con la misma opción un "time" systemd-analyze Si la ejecutamos tal cual, sin ninguna otra opción nos devolverá una estimación (muy precisa) del tiempo que emplearía el sistema en arrancar con la configuración actual, diferenciando de manera clara y por separado el tiempo correspondiente al kernel en sí y al espacio de usuario: root@Shiba87:/home/shiba# systemd-analyze Startup finished in 3.315s (kernel) + 13.375s (userspace) = 16.691s Ahora que sabemos cuál es nuestro tiempo de arranque, podemos empezar a trabajar para optimizarlo y/o reducirlo haciendo uso del resto de opciones de systemd-analyze y, por supuesto, systemctl. Empezamos por pedirle una lista detallada de todos los servicios que se inician al arrancar el sistema y su impacto en el tiempo total de arranque: systemd-analyze blame Ahora la respuesta será mucho más extensa y concisa root@Shiba87:/home/shiba# systemd-analyze blame 11.440s systemd-fsck-root.service 1.108s keyboard-setup.service 1.069s sys-kernel-debug.mount 1.068s dev-mqueue.mount 1.067s dev-hugepages.mount 830ms systemd-udevd.service 762ms systemd-udev-trigger.service 684ms systemd-tmpfiles-setup-dev.service 408ms systemd-modules-load.service 404ms systemd-sysctl.service 355ms vboxdrv.service 247ms home.mount 124ms cron.service 111ms systemd-readahead-replay.service 95ms systemd-update-utmp-runlevel.service 85ms console-setup.service 77ms systemd-tmpfiles-clean.service 72ms systemd-remount-fs.service 52ms networking.service [...] O podemos centrarnos específicamente en los más lentos: systemd-analyze blame | head Nos quedaría sólo con los tiempos de cabeza, es decir, los más lentos root@Shiba87:/home/shiba# systemd-analyze blame | head 11.440s systemd-fsck-root.service 1.108s keyboard-setup.service 1.069s sys-kernel-debug.mount 1.068s dev-mqueue.mount 1.067s dev-hugepages.mount 830ms systemd-udevd.service 762ms systemd-udev-trigger.service 684ms systemd-tmpfiles-setup-dev.service 408ms systemd-modules-load.service 404ms systemd-sysctl.service También podemos centrarnos en los puntos "críticos" systemd-analyze critical-chain Y que nos devuelva una estructura clara y en orden de todos ellos. root@Shiba87:/home/shiba# systemd-analyze critical-chain The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. graphical.target @13.279s └─multi-user.target @13.278s └─vboxweb-service.service @13.275s +2ms └─vboxdrv.service @12.918s +355ms └─basic.target @12.916s └─sockets.target @12.916s └─dbus.socket @12.915s └─sysinit.target @12.914s └─console-setup.service @12.828s +85ms └─kbd.service @12.818s +8ms └─remote-fs.target @12.817s └─local-fs.target @12.816s └─home.mount @12.568s +247ms └─local-fs-pre.target @12.270s └─systemd-remount-fs.service @12.197s +72ms └─keyboard-setup.service @2.165s +1.108s └─systemd-udevd.service @1.334s +830ms └─systemd-tmpfiles-setup-dev.service @648ms +684ms └─systemd-journald.socket @645ms └─-.mount @630ms Otras opciones interesantes son plot y dot, que nos permiten realizar gráficos con toda la información anterior para que nos sea más sencillo procesarla de una manera más "visual". El gráfico será devuelto en forma de imagen svg, así que a menos que queramos ver una enorme lista de puntos uno tras otros, tendremos que indicar también el archivo de destino donde irán a parar los datos: systemd-analyze plot >> archivo-grafico.svg El resultado es una imagen gigantesca con todos los servicios, sus tiempos y una serie de indicaciones que nos serán muy útiles para analizar los datos de systemd Analyze Para el diagrama de puntos tendremos que ser incluso más específicos a la hora de crear el archivo svg y necesitaremos hacer uso de las herramientas del paquete graphviz systemd-analyze dot | dot -Tsvg > Archivo-diagrama.svg El resultado es... bueno, difícil de describir con palabras Como ven tenemos un diagrama muy complejo de todos los servicios y las dependencias entre ellos, el orden que ocupan... en fin, una maraña de información muy muy completa Para quienes quieran profundizar más en las herramientas de análisis, toda la información se encuentra en las Wikis oficiales y en las de muchas distribuciones http://www.freedesktop.org/software/systemd/man/systemd-analyze.html Optimizando el Arranque Una vez que tengamos una idea clara de cómo es la secuencia de arranque de nuestro sistema, podemos ponernos manos a la obra para optimizarla. Habilitando/deshabilitando servicios Aunque no era mi intención en cuanto a métodos de optimización empezaré por lo más obvio y que seguramente todos tenemos ahora mismo rondando por nuestra cabeza, que viene siendo deshabilitar directamente algunos servicios que no necesitamos. Esto es bastante sencillo, simplemente elegiremos aquellos demonios de la lista que nos ha devuelto el systemd-analyze que no queremos que sean cargados y, mediante el uso de systemctl, nos desharemos de ellos systemctl disable demonio.service O, si por el contrario quisiéramos realizar el proceso inverso, es decir, habilitar un servicio systemctl enable demonio.service Así con cada uno de los demonios con los que trabajemos. Readahead Pero no es eso de lo que venía a hablar aquí, sino de otras formas de optimizar el arranque, como puede ser readahead. Algo tan sencillo como systemctl enable systemd-readahead-collect systemd-readahead-replay nos permitirá optimizar de manera sensible el arranque de nuestro sistema. Preload Incluido en los repositorios de algunas distribuciones, nos permitirá realizar una análisis de las funciones y demonios más utilizados en el sistema para cargarlos antes de necesitarlos, lo que redundará en una mejor respuesta del sistema y esto a su vez, en un arranque más agilizado. Para los que no podemos instalar preload desde repositorios, el proceso para activarlo sería el siguiente: wget http://optimate.dl.sourceforge.net/project/preload/preload/0.6.4/preload-0.6.4.tar.gz tar -xfvz preload*.tar.gz cd preload* ./configure make make install Tras la instalación, habilitamos el servicio y lo ponemos en marcha: systemctl start preload.service systemctl enable preload.service Prelink Sólo nos queda hablar de prelink, igualmente en respositorios de muchas distribuciones y que nos permitirá agilizar no sólo el arranque sino la ejecución de muchas aplicaciones al realizar enlaces entre binarios y librerías o más bien "pre-enlaces", acelerando la ejecución de las mismas. una vez instalado el paquete, la primera vez ejecutaremos directamente prelink -afmR Y le dejaremos obrar su magia. En ocasiones posteriores, como las librerías y aplicaciones cambian, se actualizan, se instalan nuevas, se desinstalan antiguas, etc, configuraremos Prelink para que busque cambios y se ejecute de forma periódica. Editamos el archivo /etc/default/prelink cambiando la línea: PRELINKING=no por PRELINKING=yes más abajo tendremos las opciones de chequeo: PRELINK_FULL_TIME_INTERVAL= Y de ejecución forzada en caso de no haberse encontrado ningún cambio en las librerías del sistema PRELINK_NONRPM_CHECK_INTERVAL= El número que acompaña a dichas opciones representa los días que pasarán entre un chequeo/ejecución y la siguiente UPower UPower es un demonio, un API, y un conjunto de herramientas de línea de comandos. Cada fuente de poder del sistema es representada como un dispositivo, sin importar que sea o no un dispositivo físico. La administración realizada por este servicio consigue que durante el arranque las unidades se inicien y sincronicen con DBus de manera más eficiente, redundando en un arranque más rápido. Aunque se puede configurar de multitud de maneras diferentes según lo que necesitemos, en principio la configuración básica es más que suficiente, basta con instalar el paquete upower y habilitar el servicio systemctl enable upower Montar/chequear particiones "secundarias" tras el arranque Una de las cosas que más puede demorar el arranque son las tareas llevadas a cabo por fsck y mount. Con el objetivo de aligerar estos procesos podemos indicar como opción en nuestro fstab que aquellas particiones que no están estrictamente necesarias para el arranque sean montadas/montada después de éste, al acceder por primera vez a ellas. Particiones como /home o algunas que hemos creado para temas concretos, discos secundarios, etc. Especialmente aquellas que no es seguro que vayamos a utilizar y, por tanto, no vale la pena estar cargándolas y revisándolas continuamente cada vez que arrancamos el equipo. En el caso concreto de /home, permitirá que otros servicios no dependientes de éste sean cargados durante el arranque antes y durante el montaje/checkeo del propio home Las opciones a las que nos referimos son: noauto, que es la opción habitual para indicar que no se monte dicha partición de manera automática x-systemd.automount, que indica que no va a ser montada ni chequeada durante el arranque sino cuando se demande. Ejemplo Bootchart Por último, a modo de curiosidad, otro proceso que antes realizamos de manera manual, pero que también podemos realizar de manera automática. Gracias al servicio bootchart lograremos crear un gráfico de nuestra secuencia de arranque. Para eso, a la línea del kernel de nuestro grub habrá que añadir las siguientes opciones initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart Y habilitar el servicio bootchart, por su puesto. systemctl enable bootchart
  3. Llego unos cuantos meses tarde, pero hay que contarlo, así que más vale tarde que nunca Red Hat anuncia que el Gobierno de Canarias ha migrado sus sistemas virtualizados de VMware a Red Hat Enterprise Virtualization para responder a sus crecientes necesidades de TI. La nueva infraestructura, basada en Red Hat Enterprise Virtualization, JBoss Enterprise Middleware y Red Hat Enterprise Linux, está diseñada para dar soporte a toda la infraestructura de telecomunicaciones, tecnologías de la información y comunicaciones informáticas del Gobierno de Canarias. La migración ha mejorado los ratios de consolidación de máquinas virtuales por servidor y permitido un ahorro de hasta el 70% frente a la plataforma de virtualización anterior. Debido a la creciente carga de trabajo soportada por la infraestructura de virtualización del Gobierno de Canarias, la organización tomó la decisión de renovarla, marcándose dos objetivos principales. En primer lugar, fomentar la convergencia entre crecimiento horizontal y crecimiento vertical, para llevar las máquinas físicas a su máxima capacidad y reducir de este modo el número de hosts, incrementando la eficiencia y reduciendo costes. Y en segundo lugar, adoptar una solución de virtualización que pudieran dar respuesta a sus necesidades reales, reduciendo el coste de propiedad todo lo posible y sin riesgos en la calidad del servicio o de continuidad futura de la solución. Tras evaluar diferentes opciones, el organismo público encontró en Red Hat Enterprise Virtualization una solución con mayor capacidad, más económica y con grandes garantías de servicio y continuidad. La propuesta planteada por Red Hat proporcionaba un ahorro de costes de hasta el 70% respecto a otras soluciones propietarias, al tiempo que permitía a su departamento de TI abordar un plan de modernización perfectamente adaptado a las necesidades del Gobierno de Canarias. Una vez completada la implantación de Red Hat Enterprise Virtualization en sus sistemas de TI, el Gobierno de Canarias consiguió pasar de unos ratios de consolidación media de siete máquinas virtuales por servidor físico a veintisiete máquinas virtuales por host, además de conseguir un ahorro del 10% de espacio en disco, mayores capacidades de reporting y una simplificación general de la arquitectura. Afirma Roberto Moreno Díaz, Director General de Telecomunicaciones y Nuevas Tecnologías del Gobierno de Canarias. http://es.redhat.com/resourcelibrary/case-studies/canary-islands-government-migrates-telecommunications-platform-from-vmware-to-red-hat
×
×
  • Crear Nuevo...