Ir al contenido

Buscar en La Comunidad

Mostrando resultados por etiquetas 'ram'.

  • 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 6 resultados

  1. Hola gente, ante de ayer eh comprado un VPS a un amigo, pero resulta que este dispone de algunos detalles: 256MB RAM parecera poco, pero yo tengo una compu lentium 2 con 128MB y va de maravilla consume 112mb con Vesta panel, apache, nginx, mysql, y todo lo que viene por defecto, no entiendo por que se da este problema, para que tengan una referencia del sistema el cual estoy hablando les dejo el siguiente log seguido de un enlace en pastebin para no sobre cargar al sitio. El enlace a pastebin https://pastebin.com/PFSM1PhY Agradecere su me ayudan a aligerar la carga del sistema operativo. root@ml:~# cat /etc/*-release* PRETTY_NAME="Debian GNU/Linux 7 (wheezy)" NAME="Debian GNU/Linux" VERSION_ID="7" VERSION="7 (wheezy)" ID=debian ANSI_COLOR="1;31" HOME_URL="http://www.debian.org/" SUPPORT_URL="http://www.debian.org/support/" BUG_REPORT_URL="http://bugs.debian.org/" root@ml:~#
  2. Hacía tiempo que quería escribir algo parecido, pero he de reconocer que me había olvidado por completo y hasta hoy no me ha venido de nuevo a la memoria y viendo que hay por ahí quien ya se me ha adelantado ¿Por qué no? El initrd (Init Ram Disc) o, en la actualidad, initramfs, es un sistema temporal de archivos utilizado durante el arranque del sistema y tiene como misión cargar en ram aquellos módulos y otros elementos necesarios para el arranque del sistema y que son necesarios antes de que haya sido montado el directorio raíz. Es decir, suministra al kernel aquellos módulos que no han sido incluido en él pero que son necesarios para poder arrancar el equipo. Sin embargo, puede ocurrir que las imágenes de arranque por defecto de un disco de instalación, en este ejemplo Debian, no tengan los módulos que necesitamos para que el sistema arranque o que no lo haga como es debido, así que no nos queda otra que remangarnos y poner manos a la obra No me voy a parar a describir el proceso de compilación de módulos del kernel, eso es otro tema, sólo la parte que corresponde a la modificación de la imagen y posterior "reempaquetado". COmpilar Kernels y módulos ya lo hemos tratado antes: Como era de esperar, necesitaremos la imagen o imágenes de arranque para poder trabajar con ellas. Lo habitual es que estén incluidas en la imagen iso de Debian, pero la versión más reciente y actualizada la encontraremos también en la ftp de Debian junto con dichas imágenes de instalación. En este caso me interesan las imágenes de arranque de una Debian Testing Amd64, por lo que me voy a buscar las imágenes del installer-amd64 actuales http://ftp.debian.org/debian/dists/testing/main/installer-amd64/current/images/ Vemos que aquí tenemos 3 opciones distintas Neetbot Cdrom Hd-media Depende de la imagen de instalación que queramos modificar, nos decantaremos por una o por otra. Yo me iré a por la Netboot, que me hace ilusión axel http://ftp.de.debian.org/debian/dists/testing/main/installer-amd64/current/images/netboot/debian-installer/amd64/initrd.gz axel http://ftp.de.debian.org/debian/dists/testing/main/installer-amd64/current/images/netboot/debian-installer/amd64/linux Vemos que me he descargado ambas, tanto la imagen de Linux como la initrd.img Descomprimirla para trabajar con ella no requerirá demasiado esfuerzo, pero puede no resultar tan intuitivo como cabría esperar, ya que se trata de una archivo cpio comprimido y teniendo en cuenta que nos va a descomprimir un gran número de directorios separados, lo mejor que podemos hacer es trabajar dentro de una carpeta aislada para no volvernos locos después. mkdir initrd cp initrd.gz initrd cd initrd gzip -cd initrd.gz | cpio -id El resultado de descomprimir la imagen será parecido al directorio raíz de un sistema instalado root@Shiba:/home/shiba/initrd# ls -la total 24240 drwxr-xr-x 17 shiba shiba 4096 abr 21 12:35 . drwxr-xr-x 36 shiba shiba 24576 abr 21 12:34 .. drwxr-xr-x 2 root root 4096 abr 21 12:35 bin drwxr-xr-x 2 root root 4096 abr 21 12:36 dev drwxr-xr-x 12 root root 4096 abr 21 12:35 etc -rwxr-xr-x 1 shiba shiba 456 abr 21 12:35 init drwxr-xr-x 2 root root 4096 abr 21 12:35 initrd -rw-r--r-- 1 shiba shiba 24719513 abr 21 12:34 initrd.gz drwxr-xr-x 14 root root 4096 abr 21 12:35 lib drwxrwxr-x 2 root root 4096 abr 21 12:35 lib64 drwxr-xr-x 2 root root 4096 abr 21 12:35 media drwxr-xr-x 2 root root 4096 abr 21 12:35 mnt drwxr-xr-x 2 root root 4096 abr 21 12:35 proc drwxr-xr-x 2 root root 4096 abr 21 12:35 run drwxr-xr-x 2 root root 4096 abr 21 12:35 sbin drwxr-xr-x 2 root root 4096 abr 21 12:35 sys drwxrwxr-x 2 root root 4096 abr 21 12:35 tmp drwxrwxr-x 6 root root 4096 abr 21 12:35 usr drwxrwxr-x 6 root root 4096 abr 21 12:35 var En este punto ya estaríamos en disposición de compilar los módulos que necesitamos incluir y colocarlos en los directorios correspondientes, que como cualquier sistemas debería ser /lib/modules/Versión-arquitectura/kernel. Eso sí, tengamos en cuenta precisamente lo que he marcado en rojo, la versión y arquitectura del kernel en el que está basado la imagen. Por ejemplo, sustituir el módulo ath9k para una tarjeta wifi muy nueva que blablabla no nos interesa la historia... root@Shiba:/lib/modules# find . -name ath9k.ko ./4.9.0-1-amd64/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko ./4.9.0-2-amd64/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko Pues compilamos por separado la versión funcional del módulo y lo sustituimos ahí para que luego sea cargado por el instalador. Así de sencillo cp ath9k.ko ~/initrd/lib/modules/4.9.0-2-amd64/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko Puede ocurrir y ocurre que cuando nos enfrentamos a la tarea de compilar un módulo para una versión de Linux concreta, el sistema desde el que lo hacemos trabaja con otra diferente y las cosas se ponen un poco complicadas. Una forma un poco bruta pero funcional de lidiar con esto e modificar el archivo make para modifica o añadir la opción de compilar para la versión concreta a la que apuntamos: Si no se trata de sustituir sino de incluir un módulo que no está incluido en la imagen initrd original, el proceso es idéntico, copiaríamos el módulo en el lugar que le correspondería dentro de /lib/modules, creando los directorios necesarios, pero tendríamos también que modificar el archivo init para que sea tenido en cuenta y cargado durante el arranque. Dicho archivo lo encontraremos en lo que sería el directorio raíz de la imagen initrd, en mi caso: root@Shiba:/home/shiba/initrd# nano init #!/bin/sh -e # used for initramfs export PATH . /lib/debian-installer/init-debug debugshell "just booted" mount /run mkdir -p /run/lock mount /proc mount /sys /lib/debian-installer/start-udev init='/bin/busybox init' for i in $(cat /proc/cmdline); do case $i in init=/init|init=init) # Avoid endless loop : ;; init=*) init=${i#init=} ;; noshell) sed -i '/^tty[23]/s/^/#/' /etc/inittab ;; esac done debugshell "before init" exec $init Y no nos complicamos en absoluto, simplemente cargamos dicho módulo, con la ruta recién creada bien definida, haciendo uso de modprobe Pero como ya he dicho, mi intención es no pararme a describir el proceso de compilar un módulo para el kernel sino otros menesteres y ya que estoy metido en faena y era una tarea que tenía pendiente, voy a modificar los banners que se muestran en el instalador de Debian para ajustarlos a GNU/Linux Vagos y que todo se vea más bonito ¿Qué les parece? Que por cierto, se encuentra dentro del directorio install o install-arquitectura y ya que los banners que quiero cambiar son para la versión gráfica, será la imagen initrd GTK, la otra es para el modo texto. Y sí, así de complicado es esto Una vez descomprimida, para encontrar los banners del instalador debemos mirar dentro de /usr/share/graphics y sustituirlos por los que queremos incluir con el nombre de logo_debian.png o logo_debian_dark.png, depende de si luego fijamos el tema claro u oscuro Los he hecho deprisa y corriendo, tampoco se pongan muy exigentes Evidentemente, los temas gtk2 los encontraremos, como es de esperar, en /usr/share/themes y por defecto habrán dos, Clearlooks y Dark. Quien quiera ponerse con el aspecto de la ventana del instalador, tiene vía libre para modificar los archivos gtrkc como si no hubiera mañana para que luzca como mejor le parezca. Yo me limitaré a poner el oscuro por defecto y poco más, que saben que a mí las cuestiones de personalización no me atraen mucho que digamos Y una vez nos hayamos quedado a gusto añadiendo y modificando módulos y poniendo paras arriba el instalador ha llegado la hora de volver a comprimir la imagen de arranque para incluirla en la imagen iso de instalación de Debian. En definitiva, comprimamos la imagen initrd que es a lo que venimos find . | cpio -o -H newc | gzip > ../initrd.gz Y reempaquetamos la imagen iso de instalación de Debian, que también está perfectamente descrito en el foro, as que no me hagan repetirme Si no la he cagado demasiado ahora, cuando arranque la imagen de instalación de Debian, se cargarán los banners y el tema que he definido en la imagen de arranque y el instalador de Debian que dará precioso y cuco O bueno... que conste yo ya avisé que las cuestiones de personalización no eran precisamente mi fuerte Vamos a intentar arreglarlo como buenamente se pueda, pero no prometo nada
  3. Me estaba empezando a preocupar, porque mi PC (que dejo prendida permanentemente) se me quedaba sin RAM cada dos semanas, no entendía por qué. Al hacer el comando "free" uno puede ver cuanta memoria RAM tiene disponible, por ejemplo tenía algo como esto (creo que era así): total used free shared buffers cached Mem: 3,3G 2,9G 0,4G 8,7M 11M 2,8G -/+ buffers/cache: 79M 3,2G Swap: 3,7G 0B 3,7G Solamente 0,4GB disponibles de 4GB totales???. La PC es un servidor y necesita menos de 150MB de RAM (me sobra RAM a montones, no conseguí memoria más chica) Estaba leyendo mal, como dice en el sitio http://www.linuxatemyram.com/ la memoria se llena con cachés utilizados para mejorar el rendimiento, pero cuando una aplicación necesita memoria ese espacio es liberado. Al final lo que hay que ver es la segunda columna. Pongo esto acá, a ver si le pasa a alguien más.
  4. Cuando me quedo sin RAM se me empiezan a pasar cosas a la swap, según entiendo esa es la función. El problema es que se empieza a poner todo lento, supongo que es porque el disco duro no es tan rápido como una RAM, se pone lento todo, los menúes contextuales, el cambio de espacio de trabajo, etc. Quería saber si hay alguna forma de determinar cuáles son las cosas que deberían pasarse a swap, para impedir que XFCE se valla a la swap y siga todo rápido. Por ejemplo estoy convirtiendo mapas de OSM de 2GB a otro formato para usarlos en el celular, como tengo solamente 4 GB de RAM ese programa me deja sin ram y me pasa todo a swap dejandome lenta la compu, además es como que se traba y nunca termina de convertirse. ¿Hay alguna forma de decirle a Linux que ejecute ese programa en la swap? ¿O de decirle que deje XFCE en la RAM?
  5. /tmp es un directorio volátil donde se almacenan los datos temporales utilizados por las aplicaciones y usuarios y cuyo contenido es borrado al terminar la sesión o reiniciar el sistema. Este directorio está montado por defecto en una de las particiones del disco duro (HDD o SSD), comunmente en la partición raíz. En situaciones en las que se haga un uso intensivo de este directorio, como a la hora de compilar el código fuente de algún software o servidores que vean mermado su rendimiento por escribir gran cantidad de datos en temporales, podría no ser conveniente tenerlos de esta manera. Por esto, montar el directorio /tmp directamente en la ram puede suponer un gran aumento del rendimiento, pues la tasa de lectura/escritura de la memoria Ram es muy superior a la de cualquier Disco duro convencional o SSD. No obstante, también debemos tener en cuenta que el espacio que ocupen los temporales en RAM no podrá ser utilizado para otras tareas. La clave para realizar este proceso es TMPFS, el cual nos permitirá montar los temporales en ram como si fuera otra partición más del disco duro, pero con un sistema de archivos diferente. Montaje Manual mediante el comando MOUNT Para un montaje no permanente que nos permita realizar una tarea concreta y luego poder devolver el sistema a la normalidad, podemos utilizar directamente mount especificando que lo que queremos es montar los temporales en ram con tmpfs. Además de eso, podemos utilizar y combinar las opciones propias de mount para que el montaje se realice según sea conveniente. Una manera simple de hacerlo sería la siguiente: En este caso hemos puesto los permisos del directorio /tmp a 1777 para que las aplicaciones/usuarios no tengan problemas a la hora de utilizar los nuevos temporales. Sin embargo podríamos querer ir más allá en lo que opciones se refiere y, por ejemplo, permitir a un único usuario utilizar estos nuevos temporales: De esta forma, el nuevo directorio /tmp, tendrá como usuario y grupo (uid/gid) el que nosotros designemos. Además de cambiar los permisos a 750 para que esta medida sea efectiva. Al tratarse de un cambio temporal, en cuanto reiniciemos el equipo todo volverá a la normalidad. También podríamos desmontar dicha partición mediante el uso de umount, siempre y cuando no esté en uso. Haciendo el cambio permanente gracias a FSTAB Editando el archivo de configuración /etc/fstab, podremos hacer este cambio permanente, consiguiente que los temporales se monten siempre en la memoria RAM, aunque en este caso conviene tener algunas consideraciones extra a la hora de elegir las opciones de montaje Una de esas opciones es size, que nos permitirá limitar el tamaño del directorio /tmp, para evitar que ocupe una cantidad de ram mayor de la esperada y nos veamos en problemas. Por ejemplo, para unos temporales de 2GB, añadiríamos lo siguiente: Para cualquier otro valor sólo hay que modificar la cantidad especificada en esa opción. Podríamos utilizar cualquier otra opción , como noexec, para no permitir ejecutar nada desde esa partición, nodev, nosuid, etc Una vez guardados los cambios, tendremos que montar manualmente la partición o reiniciar el equipo (sólo la primera vez, a partir de ahí el montaje se tmpfs realizará de manera automática)
  6. La semana pasada estuvimos hablando bastante sobre la futura versión del Linux kernel 3.8. Esta sera una versión recordada en la rama 3.X, incluso en la historia del kernel por traer cambios radicales que van a mejorar mucho el kernel y todas las distribuciones GNU/Linux. El jueves pasado comentamos en Leanuxeros que la versión 3.8 del Linux kernel ya no soportara los procesadores Intel 386 y sus clones. También estuvimos hablando sobre la capacidad de poder desconectar y quitar procesadores en caliente para el hardware que lo soporte, característica que mejorara mucho la productividad en entornos empresariales. Cuando Linus Torvalds publico la versión 3.7 del Linux kernel la semana pasada, hicimos un repaso de los cambios que traía. Una de las mejoras era el consumo de memoria y la utilización de memoria en sistemas SMPtanto en procesadores multi-núcleo como en sistemas multi-procesador. La versión 3.8 promete seguir dejando al Linux kernel como una referencia en tecnología de vanguardia donde muy pocos sistemas operativos pueden llegar. Recuerdo cuando salio la rama 2.6.X del Linux kernel que gestionaba muchísimo mejor la memoria RAM, llegando a consumir hasta un 30% menos en situaciones idénticas que la rama 2.4.X. Esto era tan beneficioso que incluso en ordenadores antiguos de los 90 donde se suponía que compilar nuevas versiones poco podía aportar al rendimiento, mejoro considerablemente la productividad y rendimiento al consumir menos recursos en ordenadores que ya de por si iban justos con lo que tenían. Algo similar ocurre con la versión 3.8, el beneficio de utilizar esta versión en comparación con anteriores versiones es un desempeño mucho mas fluido del sistema operativo y mas recursos disponibles para los programas, lo que para maquinas modernas esta bien, pero mejor aun para maquinas mas antiguas donde empiezan a sudar con las ultimas versiones de software. Linus Torvalds ha comentado que todavía esta clasificando una serie de parches que han programado los desarrolladores habituales del Linux kernel. Pero que cuando este disponible la primera versión Release Candidate del Linux kernel 3.8, este ya llevara todos los parches necesarios para el nuevo sistema de gestión de memoria RAM. Cabe mencionar que Intel es una de las empresas que ha contribuido en el nuevo sistema de gestión de memoria RAM. El nuevo sistema esta relacionado en como trabaja la cache y paginación en el kernel, cumpliendo su objetivo mucho mas eficiente y rápido que en anteriores versiones. De momento es pronto para sacar una conclusión definitiva ni hacer pruebas, puesto que aun no esta disponible la primera versión Release Candidate. Pero lo que es seguro es que el Linux kernel 3.8 promete avances que hace tiempo no vemos en el desarrollo del kernel. Uno de los puntos que han ayudado al nuevo sistema de gestión de memoria, es la eliminación del soporte de procesadores 386, simplificando la complejidad del kernel y centrando mas los esfuerzos de los programadores en nuevas funciones. Fuente: Phoronix
×
×
  • Crear Nuevo...