LINUX.ORG.RU

История изменений

Исправление chukcha, (текущая версия) :

Данная TV-приставка имеет на борту неплохое количество памяти - 4 ГБ.
Их них разработчик дистрибутива оттяпал 1 ГБ и приспособил их для ZRAM. Используемая компрессия данных довела объем свопа до ~5 ГБ, что в общем-то достаточно.

Однако на практике оказалось, что современные Firefox, которые жрут немерянное количество памяти, часто заполняют swap до отказа, и система переходит в коматозное состояние.
Т.е. она не зависает, но не реагирует на мышь и клавиатуру, поскольку идет интенсивный обмен с SSD-диском по шине USB, общей для всей периферии.
Выкручивался ребутом по ssh.

Потом эти случаи надоели, и добавил раздел с дополнительным свопом на 8 ГБ.

В итоге fstab выглядит следующим образом -

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
PARTUUID=5aaeeb41-01  /boot   vfat    defaults,noexec,nodev,showexec  0   0
PARTUUID=5aaeeb41-01  /boot   vfat    defaults            0   0
PARTUUID=5aaeeb41-02  /       ext4    defaults            0   1
PARTUUID=5aaeeb41-03  none    swap    defaults,pri=10     0   0
Чтобы дополнительный swap вступал в действие после основого, присвоил ему более низкий приоритет 10.

В итоге работа обеих свопов выглядит слудующим образом -
# swapon -show
Filename				Type		Size		Used	Priority
/dev/sda3                               partition	8387580		0	10
/dev/zram0                              partition	5112992		859136	100

Здесь видно, что благодаря разным приоритетам основной своп начал заполнятся, а дополнительный ждет своей очереди.

PS. Почему boot-разделу в fstab присвоены 2 строки, сам бы хотел знать.
Так было изначально, поэтому решил не трогать.

Исправление chukcha, :

Данная TV-приставка имеет на борту неплохое количество памяти - 4 ГБ.
Их них разработчик дистрибутива оттяпал 1 ГБ и приспособил их для ZRAM. Используемая компрессия данных довела объем свопа до ~5 ГБ, что в общем-то достаточно.

Однако на практике оказалось, что современные Firefox, которые жрут немерянное количество памяти, часто заполняют swap до отказа, и система переходит в коматозное состояние.
Т.е. она не зависает, но не реагирует на мышь и клавиатуру, поскольку идет интенсивный обмен с SSD-диском по шине USB, общей для всей периферии.
Выкручивался ребутом по ssh.

Потом эти случаи надоели, и добавил раздел с дополнительным свопом на 8 ГБ.

В итоге fstab выглядит следующим образом -

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
PARTUUID=5aaeeb41-01  /boot   vfat    defaults,noexec,nodev,showexec  0   0
PARTUUID=5aaeeb41-01  /boot   vfat    defaults            0   0
PARTUUID=5aaeeb41-02  /       ext4    defaults            0   1
PARTUUID=5aaeeb41-03  none    swap    defaults,pri=10     0   0
Чтобы дополнительный swap вступал в действие после основого, присвоил ему более низкий приоритет 10.

В итоге работа обеих свопов выглядит слудующим образом -
# swapon -show
Filename				Type		Size		Used	Priority
/dev/sda3                               partition	8387580		0	10
/dev/zram0                              partition	5112992		859136	100

Здесь видно, что основной своп начал заполнятся, а дополнительный ждет своей очереди.

PS. Почему boot-разделу в fstab присвоены 2 строки, сам бы хотел знать.
Так было изначально, поэтому решил не трогать.

Исправление chukcha, :

Данная TV-приставка имеет на борту неплохое количество памяти - 4 ГБ.
Их них разработчик дистрибутива оттяпал 1 ГБ и приспособил их для ZRAM. Используемая компрессия данных довела объем свопа до ~5 ГБ, что в общем-то достаточно.

Однако на практике оказалось, что современные Firefox, которые жрут немерянное количество памяти, часто заполняют swap до отказа, и система переходит в коматозное состояние.
Т.е. она не зависает, но не реагирует на мышь и клавиатуру, поскольку идет интенсивный обмен с SSD-диском по шине USB, общей для всей периферии.
Выкручивался ребутом по ssh.

Потом эти случаи надоели, и добавил раздел с дополнительным свопом на 8 ГБ.

В итоге fstab выглядит следующим образом -

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
PARTUUID=5aaeeb41-01  /boot   vfat    defaults,noexec,nodev,showexec     0   0
PARTUUID=5aaeeb41-01  /boot   vfat    defaults            0   0
PARTUUID=5aaeeb41-02  /       ext4    defaults            0   1
PARTUUID=5aaeeb41-03  none    swap    defaults,pri=10     0   0
Чтобы дополнительный swap вступал в действие после основого, присвоил ему более низкий приоритет 10.

В итоге работа обеих свопов выглядит слудующим образом -
# swapon -show
Filename				Type		Size		Used	Priority
/dev/sda3                               partition	8387580		0	10
/dev/zram0                              partition	5112992		859136	100

Здесь видно, что основной своп начал заполнятся, а дополнительный ждет своей очереди.

PS. Почему boot-разделу в fstab присвоены 2 строки, сам бы хотел знать.
Так было изначально, поэтому решил не трогать.

Исправление chukcha, :

Данная TV-приставка имеет на борту неплохое количество памяти - 4 ГБ.
Их них разработчик дистрибутива оттяпал 1 ГБ и приспособил их для ZRAM. Используемая компрессия данных довела объем свопа до ~5 ГБ, что в общем-то достаточно.

Однако на практике оказалось, что современные Firefox, которые жрут немерянное количество памяти, часто заполняют swap до отказа, и система переходит в коматозное состояние.
Т.е. она не зависает, но не реагирует на мышь и клавиатуру, поскольку идет интенсивный обмен с SSD-диском по шине USB, общей для всей периферии.
Выкручивался по ssh.

Потом эти случаи надоели, и добавил раздел с дополнительным свопом на 8 ГБ.

В итоге fstab выглядит следующим образом -

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
PARTUUID=5aaeeb41-01  /boot   vfat    defaults,noexec,nodev,showexec     0   0
PARTUUID=5aaeeb41-01  /boot   vfat    defaults            0   0
PARTUUID=5aaeeb41-02  /       ext4    defaults            0   1
PARTUUID=5aaeeb41-03  none    swap    defaults,pri=10     0   0
Чтобы дополнительный swap вступал в действие после основого, присвоил ему более низкий приоритет 10.

В итоге работа обеих свопов выглядит слудующим образом -
# swapon -show
Filename				Type		Size		Used	Priority
/dev/sda3                               partition	8387580		0	10
/dev/zram0                              partition	5112992		859136	100

Здесь видно, что основной своп начал заполнятся, а дополнительный ждет своей очереди.

PS. Почему boot-разделу в fstab присвоены 2 строки, сам бы хотел знать.
Так было изначально, поэтому решил не трогать.

Исправление chukcha, :

Данная TV-приставка имеет на борту неплохое количество памяти - 4 ГБ.
Их них разработчик дистрибутива оттяпал 1 ГБ и приспособил их для ZRAM. Используемая компрессия данных довела объем свопа до ~5 ГБ, что в общем-то достаточно.

Однако на практике оказалось, что современные Firefox, которые жрут немерянное количество памяти, часто заполняют swap до отказа, и система переходит в коматозное состояние.
Т.е. она не зависает, но не реагирует на мышь и клавиатуру, поскольку идет интенсивный обмен с SSD-диском по шине USB, обшей для всей периферии.
Выкручивался по ssh.

Потом эти случаи надоели, и добавил раздел с дополнительным свопом на 8 ГБ.

В итоге fstab выглядит следующим образом -

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
PARTUUID=5aaeeb41-01  /boot   vfat    defaults,noexec,nodev,showexec     0   0
PARTUUID=5aaeeb41-01  /boot   vfat    defaults            0   0
PARTUUID=5aaeeb41-02  /       ext4    defaults            0   1
PARTUUID=5aaeeb41-03  none    swap    defaults,pri=10     0   0
Чтобы дополнительный swap вступал в действие после основого, присвоил ему более низкий приоритет 10.

В итоге работа обеих свопов выглядит слудующим образом -
# swapon -show
Filename				Type		Size		Used	Priority
/dev/sda3                               partition	8387580		0	10
/dev/zram0                              partition	5112992		859136	100

Здесь видно, что основной своп начал заполнятся, а дополнительный ждет своей очереди.

PS. Почему boot-разделу в fstab присвоены 2 строки, сам бы хотел знать.
Так было изначально, поэтому решил не трогать.

Исправление chukcha, :

Данная TV-приставка имеет на борту неплохое количество памяти - 4 ГБ.
Их них разработчик дистрибутива оттяпал 1 ГБ и приспособил их для ZRAM. Используемая компрессия данных довела объем свопа до ~5 ГБ, что в общем-то достаточно.

Однако на практике оказалось, что современные Firefox, которые жрут немерянное количество памяти, часто заполняют swap до отказа, и система переходит в коматозное состояние.
Т.е. она не зависает, но не реагирует на мышь и клавиатуру, поскольку идет интенсивный обмен с SSD-диском по шине USB, обшей для всей периферии.
Выкручивался по ssh.

Потом эти случаи надоели, и добавил раздел с дополнительным свопом на 8 ГБ.

В итоге fstab выглядит следующим образом -

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
PARTUUID=5aaeeb41-01  /boot   vfat    defaults,noexec,nodev,showexec     0   0
PARTUUID=5aaeeb41-01  /boot   vfat    defaults            0   0
PARTUUID=5aaeeb41-02  /       ext4    defaults            0   1
PARTUUID=5aaeeb41-03  none    swap    defaults,pri=10     0   0
Чтобы дополнительный swap вступал в действие после основого, присвоил ему более низкий приоритет 10.

В итоге работа обеих свопов выглядит слудующим образом -
# swapon -show
Filename				Type		Size		Used	Priority
/dev/sda3                               partition	8387580		0	10
/dev/zram0                              partition	5112992		859136	100

Здесь видно, что основной своп начал заполнятся, а дополнительный ждет своей очереди.

Исправление chukcha, :

Данная TV-приставка имеет на борту неплохой количество памяти - 4 ГБ.
Их них разработчик дистрибутива оттяпал 1 ГБ

Исходная версия chukcha, :

Проблема свопа...