The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз ядра Linux 3.18, opennews (??), 08-Дек-14, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


39. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от botman (ok), 08-Дек-14, 13:45 
> а до сих пор десктоп встает колом при интенсивных дисковых операциях

Предположу что swap не примонтирован или диск|оперативка битые, ещё бывало так с 32-битным ведром на ранних amd64... но это когда было уже... Сейчас на 3.16 стоит btrfs на руте и хомяк под ext4, ничего такого нету.

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

43. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 08-Дек-14, 14:00 
>> а до сих пор десктоп встает колом при интенсивных дисковых операциях
> Предположу что swap не примонтирован или диск|оперативка битые, ещё бывало так с
> 32-битным ведром на ранних amd64... но это когда было уже... Сейчас
> на 3.16 стоит btrfs на руте и хомяк под ext4, ничего
> такого нету.

У меня то же btrfs стоит, правда везде. Своп выделен и примонтирован. Так же использую zram. Если zram убрать, то вообще будет дубак системе, она частично снимает проблему хотя бы при небольшой нехватке памяти. Если дисковый свап врубается, то все, каюк, сиди, жди, я не дожидаюсь и нередко просто насильно выключаю комп. Но, с тех пор как озы стало 8Гб, эти проблемы не так сильно заметны. Потому, уже не ищу решений (а попробовано их море). В результате всех решений вывод прост, вернее их два 1. Дисковая подсистема в линуксе как то не шибко хорошо работает для десктопа. 2. Своп в линуксе вообще штука жуткая.

Я жалуюсь так, послушать ответы может действительно новое решение нашлось, пока все старое и точно не помогает, так как проверено.

Ответить | Правка | Наверх | Cообщить модератору

47. "Релиз ядра Linux 3.18"  +/
Сообщение от botman (ok), 08-Дек-14, 14:14 
> Я жалуюсь так, послушать ответы может действительно новое решение нашлось, пока все
> старое и точно не помогает, так как проверено.

Если своп начинает писать на диск... я бы подумал что в системе что-то течёт и забивает всю оперативку

Ответить | Правка | Наверх | Cообщить модератору

65. "Релиз ядра Linux 3.18"  +3 +/
Сообщение от Аноним (-), 08-Дек-14, 14:54 
> У меня то же btrfs стоит, правда везде. Своп выделен и примонтирован.
> Так же использую zram. Если zram убрать, то вообще будет дубак
> системе, она частично снимает проблему хотя бы при небольшой нехватке памяти.

Ну то-есть вы сами себе создали проблему нехваткой физической памяти и потом удивляетесь что своп - очень хреновая и медленная эмуляция опративки? И да, если прога выдавилась в своп - при налете на отсутствующую страницу программа встанет колом пока ядро не достанет ее из свопа. Если это потребует 10 секунд (мало ли на какой флопарь вы там свопились) - значит будете ждать. А куда вы денетесь?

Как сделать реально быструю систему?
- SSD под систему. Жирные данные, если их много можно на отдельный винч вынести. Можно механический. Там если что и будет клинить то только сильно отдельные программы которые эти данные лопатят.
- Достаточно RAM (>=4 Gb) для работы. А если виртуалки надо, памяти >=8Gb, как ни крути.  
- Отрубить нафиг своп.
- Для пущего шика lowlatency ядро можно поставить/собрать.

Система станет турбореактивной. I/O просто не сможет затыкаться на уровне физики в местах где вас бы это напрягло. А потуги полисовать тормозной патефон с магнитными головами где время прогона голов заранее неизвестно и реальную геометрию знает только фирмварь, которая это наружу не скажет - понятно как будет работать.

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

69. "Релиз ядра Linux 3.18"  +5 +/
Сообщение от Аноним (-), 08-Дек-14, 15:16 
> А потуги полисовать тормозной патефон с магнитными головами где время прогона голов заранее неизвестно и реальную геометрию знает только фирмварь, которая это наружу не скажет - понятно как будет работать.

Отсюда мораль: планировку очереди отдать AHCI NCQ, а ядерный шедулер взять попроще - noop, deadline, например.

Ответить | Правка | Наверх | Cообщить модератору

142. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 07:33 
> Отсюда мораль: планировку очереди отдать AHCI NCQ, а ядерный шедулер взять попроще
> - noop, deadline, например.

Отсюда мораль - в случае SSD еще можно что-то планировать, и то - неопределенность из-за действий фирмвари и ее GC - есть. А если у вас там тормозной механический диск - планировать как полетят головы вы не сможете, просто потому что информации о истинной геометрии нигде нет. А без этого планировка получается весьма номинальная. Потому что неизвестно насколько запрошенная операция вообще заклинит накопитель. Так что рассуждения о планировке - оно конечно да, а дурная природа накопителя и отсутствие сведений о геометрии никуда не денется. Так что считать планировщики серебряной пулей - наивно.

Ответить | Правка | Наверх | Cообщить модератору

172. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 12:04 
Ну так накопитель свою геометрию прекрасно знает, и буфер у него некоторый наличествует. Вот и отдай ему то, что он умеет лучше тебя, делов-то.
Ответить | Правка | Наверх | Cообщить модератору

206. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 16:53 
> Ну так накопитель свою геометрию прекрасно знает,

Зато ее не знает ядро. Поэтому попытки что-то шедулить - это круто. Только проблема в том что допущения и ожидания ядра никак не совпадают с тем что по факту будет при впихивании этого набора команд в накопитель. Поэтому как таковые потуги шедулить и полисовать механический диск - весьма интересное начинание, в плане облома ожиданий и запрыгов по граблям.

> и буфер у него некоторый наличествует.

Некоторый - да. Только по сравнению с каким-нибудь дампом оперативы на 4 гига у виртуалки - он вообще ни о чем. Нет, конечно, с ним лучше чем без него. Но он ни разу не сравнится с большим дисковым кэшом в системе у которого размер гигабайтных порядков может быть, а харду столько памяти паять всех жаба задушит.

> Вот и отдай ему то, что он умеет лучше тебя, делов-то.

А у него там фирмвара на проце ограниченной мощности и память ограниченного объема - если ты думаешь что он там мега-логику сможет очень результативно навернуть - это зря. В целом по моим наблюдениям механические диски очень не лю многопоточный доступ. С большим дисковым буфером система может свести кучу мелких записей к нескольким большим и непрерывным. Что хорошо и в плане фрагментации и скорости. И чем жирнее дисковый буфер тем больше возможностей для того чтобы сделать запись более-менее оптимально и не насилуя диск множеством seek во все стороны.

Одно дело если 4 гига дампа оперативы вм просто улетят в дисковый буфер и максимально последовательно и уже не клиня программу выдавятся на блины, и другое если там еще дюжина софтин в процессе будет хотеть что-то сделать, система будет пытаться им тоже что-то выкроить, хард будет гонять по всему блину головы и в результате все это в целом - получится медленно и печально.

Ответить | Правка | Наверх | Cообщить модератору

70. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 08-Дек-14, 15:18 
> Я жалуюсь так, послушать ответы может действительно новое решение нашлось, пока все старое и точно не помогает, так как проверено.

Список "всего старого" в студию!

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

116. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от settler001email (?), 09-Дек-14, 01:03 
/etc/sysctl.conf

vm.overcommit_ratio = 80
vm.overcommit_memory = 2
vm.dirty_bytes = 8388608
vm.dirty_background_bytes = 8388608
vm.vfs_cache_pressure = 50

помогает отлично. сам страдал много лет, нарыл решение неделю назад, когда надоело смотреть на очередное "сейчас запишу файлики на usb флешку и будет тебе кино и браузер".

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

143. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 07:35 
> смотреть на очередное "сейчас запишу файлики на usb флешку и будет
> тебе кино и браузер".

А от этого помогает ядро с починеным 12309. Теперь ядро просто не будет выстраивать огромную очередь страниц на запись для тормозного накопителя, для начала. Так что и дисковый буфер отнимать по полчаса не придется.

Ответить | Правка | Наверх | Cообщить модератору

170. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от settler001email (?), 09-Дек-14, 11:45 
Где берут это фантастическое ядро? И почему не починят 12309 в ванильном?
Ответить | Правка | Наверх | Cообщить модератору

171. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от settler001email (?), 09-Дек-14, 11:52 
> Где берут это фантастическое ядро? И почему не починят 12309 в ванильном?

upd. все ядра с периодичностью обновления 1-2 месяца за последние 10 лет.
я их все пробовал. не на всех записывал на флешку конечно, но в 3.17.4 баг есть, гарантированно приводящий к "сходи кофе попей". вышеприведенные строчки в sysctl.conf лечат проблему полностью.

Ответить | Правка | Наверх | Cообщить модератору

207. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 16:55 
> строчки в sysctl.conf лечат проблему полностью.

Звучит как будто в каких-то случаях аналог 12309 не придушили до конца. Ну то-есть похоже на то что выстраивается большая очередь страниц при тормозном накопителе. А не должна...

Ответить | Правка | Наверх | Cообщить модератору

230. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от pavlinux (ok), 10-Дек-14, 00:56 
>> строчки в sysctl.conf лечат проблему полностью.
> Звучит как будто в каких-то случаях аналог 12309 не придушили до конца.

Не придушится он, это архитектурный косяк SATA и вообще любых
последовательных интерфейсов интегрированных в чипсет.

Ответить | Правка | Наверх | Cообщить модератору

240. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 10-Дек-14, 15:17 
> Не придушится он, это архитектурный косяк SATA и вообще любых
> последовательных интерфейсов интегрированных в чипсет.

Ты чего, каркуша? Проиграл войну зеленому змею? Чем тебе архитектура не та?

Если уж архитектурно, последовательный интерфейс от параллельного отличается аж целым "лишним" блоком SERDESа по пути, который из параллельного представления делает в темпе вальса последовательное, ну и обратно. Ну ок, в SATA еще попутно всякое кодирование типа 8/10 делают, но это несколько простых и сравнительно глупых железок.

А я вообще говорил про иное: если ядру надо память - ядро может попробовать забрать ее у дискового кэша. В том числе, инициировав сброс кэша на диск и отъем этих страниц. И если накопитель тормозной а страниц на выжимку много - тот кто память попросил может довольно долго курить бамбук, что и было 12309. Его помнится починили просто затвикав поведение кэша так чтобы для тормозных дисков не было огромных очередей. И у многих недовольных вроде как все стало ок. А тут такое ощущение что подобные по смыслу грабли опять где-то вылезают.

Ответить | Правка | Наверх | Cообщить модератору

252. "Релиз ядра Linux 3.18"  +/
Сообщение от pavlinux (ok), 10-Дек-14, 22:38 
> Если уж архитектурно, последовательный интерфейс от параллельного отличается аж

Идиот, ты хотя бы для начала провода на 80-жильном SCSI посчитал, и 7 у SATA


> ... если ядру надо ...
> ... может попробовать ...
> ... И если ...
> ... может довольно долго ...
> ... И у многих ...
> ... вроде как ...
> ... такое ощущение
> ... опять где-то ...

У тебя там случаем не карты Таро, очень смахивает на гадалку.

Ответить | Правка | Наверх | Cообщить модератору

255. "Релиз ядра Linux 3.18"  +2 +/
Сообщение от mihalychemail (ok), 10-Дек-14, 23:02 
Мдааа. По ходу ты, Павлуня, окончательно деградировал в овощ.
Ответить | Правка | Наверх | Cообщить модератору

231. "Релиз ядра Linux 3.18"  +/
Сообщение от pavlinux (ok), 10-Дек-14, 01:02 
> /etc/sysctl.conf
> vm.overcommit_ratio = 80
> vm.overcommit_memory = 2
> vm.dirty_bytes = 8388608
> vm.dirty_background_bytes = 8388608
> vm.vfs_cache_pressure = 50
> помогает отлично.

К таким заявам хорошо бы прикладывать полный конфиг железа.
Мать, диски, SPD из RAMы, CPU,..., load average тоже и iostat c ним же.

Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

241. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 10-Дек-14, 15:19 
Размечтался то! Некоторые верят в серебряные пули. Ну или как ты - боятся последовательных интерфейсов. Или там чего еще. А ты эзернет не боишься? Или там HDMI, DP и прочих? А то там тоже последовательное пихание данных по дифференциальной паре, если что...
Ответить | Правка | Наверх | Cообщить модератору

256. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от settler001email (?), 10-Дек-14, 23:35 
>> помогает отлично.
> К таким заявам хорошо бы прикладывать полный конфиг железа.
> Мать, диски, SPD из RAMы, CPU,..., load average тоже и iostat c
> ним же.

и какой мне смысл это делать? ты ядерный разработчик и поправишь баг?

у линукса большие проблемы с тормозами при записи на диски, вне зависимости от того, SSD это или USB. как на бытовом железе, так и на серверном от intel (у FreeBSD при этом там всё ок). многие годы, ничего не меняется и не делается. в серебряную пулю я не верю.

крайние полторы недели писал 1-4гигабайтные файлы карт на навигатор по usb, и насмотрелся на этот баг достаточно, что-бы увидеть сказочный (но совершенно понятный) эффект от этих двух строчек (остальные про другое).

>> vm.dirty_bytes = 8388608
>> vm.dirty_background_bytes = 8388608

Ответить | Правка | К родителю #231 | Наверх | Cообщить модератору

44. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 08-Дек-14, 14:01 
И да, комп уже не первый, а проблема все та же.
Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

50. "Релиз ядра Linux 3.18"  +/
Сообщение от botman (ok), 08-Дек-14, 14:21 
> И да, комп уже не первый, а проблема все та же.

htop|top смотри, такого не бывает чтобы нельзя было увидеть что сжирает swap

Ответить | Правка | Наверх | Cообщить модератору

57. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 08-Дек-14, 14:30 
>> И да, комп уже не первый, а проблема все та же.
> htop|top смотри, такого не бывает чтобы нельзя было увидеть что сжирает swap

Я невольно немного запутал описание. Даже если своп не задействован, а просто сохраняется состоояние 4Гб виртуалки с 8Гб физической озу на компе, то есть происходят интенсивные дисковые операции по записи на диск, все равно, например, в браузере кино замрет или почта повиснет. Если же в дело вступает своп (допустим две виртуалки работает), то все, каюк, у меня терпения часто не хватает дождаться. Но  хорошо то, что две виртуалки я зпускаю только что бы иногда глянуть изменилась ли ситуация с свопом. Как он не работал толком, так и не работает. Если бы что то текло я бы это вычислил сразу.

Ответить | Правка | Наверх | Cообщить модератору

257. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Классический аноним (?), 11-Дек-14, 07:35 
Мне кажется проблема наоборот с некоторыми программулинами, которые не любят в своп уходить. На компе с 4ГБ у меня постоянно дрались chromium и qemu. В qemu запущена ОСЬ с 512МБ, т.е. в итоге максимум 1ГБ должно есть. Хрому тоже 2ГБ по уши, но буквально 10 страниц и начинааааААААААется. Даже мышь не шевелится. Можно минут 10 подождать, в процессе чего у хрома будет прибит ООМом плагин Adblock и можно дальше работать.

Что самое смешное, поставил 8ГБ ОЗУ, та же конфигурация софта за пределы 4ГБ не вылазит и при этом уже всё ОК. Т.е. налицо некорректная работа когда РАМы мало. А не реальная нехватка оной.

Ответить | Правка | Наверх | Cообщить модератору

60. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 08-Дек-14, 14:34 
> И да, комп уже не первый, а проблема все та же.

latencytop и sysdig вам в руки. Ну и просто понимание того как работает железо и как не гадить своей системе.

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

59. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 08-Дек-14, 14:33 
> на 3.16 стоит btrfs на руте и хомяк под ext4,

Типа, снапшоты самых ценных данных - роскошь? :)


Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

68. "Релиз ядра Linux 3.18"  +/
Сообщение от botman (ok), 08-Дек-14, 15:08 
Почему? Btrfs первый раз поставил, а ext4 у меня было... тупо копирую дерево с диска на диск не заморачиваясь
Ответить | Правка | Наверх | Cообщить модератору

145. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 08:12 
> Почему?

Потому что мысль снапшотить хомяка мне кажется весьма логичной. Хорошо помогает от лажи типа "rm -rf /home/somebody /some_dir/some_file". Мысль что хомяк не нуждается в такой защите мне не самоочевидна - пару раз я так очень обидно файлы портил, особенно невкусно было раскатать сравнительно старый бэкап при отсутствии более нового.

> дерево с диска на диск не заморачиваясь

Если допустить что btrfs надежно работает - логичнее было бы на самом деле оба диска в пул собрать и иногда делать снапшоты, а ценные данные так и вовсе можно разложить на зеркальный raid, например. При том это не зеркало на оба диска целиком, а только а объем ценных данных. А остальное можно без RAID. Или stripe для скорости. Я вот уже прицеливаюсь перевести на btrfs многодисковые конструкции, хоть это и потребует двигания данных. Зато есть надежда больше не налетать на такие операции в перспективе :)

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру