собрал pf-3.6.7 [1] с включенным bfq. успешно работает несколько дней,
благополучно пережил довольно большую обнову, при нагрузке на i/o не крашится и
не жалуется на жизнь.
[1] http://pf.natalenko.name/
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of
Как висла, так и виснет.
Работать невозможно.
Причём, сначала было нормально, но после выхода из hibernate и работы в течение
нескольких часов - капут. :-(
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Хотя, возможно, это связано с VmWare.
У кого-то похожее:
http://www.linux.org.ru/forum/general/7687030
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
13.10.2012 09:13, Артём Н. пишет:
Ну, на данный момент, тьфу-тьфу-тьфу, всё работает и не умирает, при большой
нагрузке на диск.
Всё-равно сдохла во время создания бэкапа: я не дождался и перезагрузил. Но
стала гораздо отзывчивей.
--
To UNSUBSCRIBE, email to
07.10.2012 19:39, dimas пишет:
ну вот, откатился на 38.8 - проблем нет. 4 дня машинка проработала как часы,
а если б электричество не кончалось сегодня утром - работала бы и дальше.
2012-276 20:50 dimas dimas...@ya.ru wrote:
а как собрал 3.5.3 - те же
грабли. причем один раз словил при
ну вот, откатился на 38.8 - проблем нет. 4 дня машинка проработала как часы, а
если б электричество не кончалось сегодня утром - работала бы и дальше.
2012-276 20:50 dimas dimas...@ya.ru wrote:
а как собрал 3.5.3 - те же
грабли. причем один раз словил при записи вообще на внешний юсб-диск
+1, та же фигня. причем началась с переходом на 3.5.3 до этого долго сидел на
38-м - система работала хоть месяцами, если с электричеством повезет. домашний
сервер-файлопомойка. а как собрал 3.5.3 - те же грабли. причем один раз словил
при записи вообще на внешний юсб-диск (точнее, но софтрейд
В Sun, 30 Sep 2012 19:39:09 +0400
Артём Н. artio...@yandex.ru пишет:
30.09.2012 19:30, Dmitry Samsonov пишет:
30.09.2012 18:29, Andrei Lomov пишет:
Да, типично, когда мало RAM и всё идет в своп.
Наблюдал при пустом и даже при выключенном свопе.
Видимо, исключительно из-за обращений к
Когда что-то интенсивно работает с диском, система зависает и перестаёт
реагировать даже на пользовательский ввод: даже курсор не двигается.
Вот как сейчас: мне приходится ждать по 10 секунд, когда появится символ.
Огонёк H.D.D. горит синим цветом.
Преимущественно обращается к диску VMWare с
On Sun, Sep 30, 2012 at 05:20:36PM +0400, Артём Н. wrote:
Когда что-то интенсивно работает с диском, система зависает и перестаёт
реагировать даже на пользовательский ввод: даже курсор не двигается.
https://bugzilla.kernel.org/show_bug.cgi?id=12309 ?
--
WBR, wRAR
signature.asc
Description:
30.09.2012 17:55, Andrey Rahmatullin пишет:
On Sun, Sep 30, 2012 at 05:20:36PM +0400, Артём Н. wrote:
Когда что-то интенсивно работает с диском, система зависает и перестаёт
реагировать даже на пользовательский ввод: даже курсор не двигается.
https://bugzilla.kernel.org/show_bug.cgi?id=12309
30.09.2012 17:20, Артём Н. пишет:
1. Нормальное ли это поведение или я где-то накосячил при конфигурировании
ядра?
Передо мной никогда не стояло задачи иметь быструю отзывчивость при
высокой нагрузке на диск (слишком редко возникали подобные ситуации, ибо
нагрузка для наблюдаемых мною
30.09.2012 18:05, Dmitry Samsonov пишет:
Передо мной никогда не стояло задачи иметь быструю отзывчивость при
высокой нагрузке на диск (слишком редко возникали подобные ситуации, ибо
нагрузка для наблюдаемых мною тормозов должна была быть реально большой,
поэтому не заморачивался)
Нагрузка
On Sun, Sep 30, 2012 at 06:00:46PM +0400, Артём Н. wrote:
30.09.2012 17:55, Andrey Rahmatullin пишет:
On Sun, Sep 30, 2012 at 05:20:36PM +0400, Артём Н. wrote:
Когда что-то интенсивно работает с диском, система зависает и перестаёт
реагировать даже на пользовательский ввод: даже курсор не
30.09.2012 18:09, Артём Н. пишет:
iceweasel+icedove+okular+rsnapshot+vmware собралась делать автоснапшот (сейчас
выключил нафиг). И, при этом, ещё может какая-нибудь база обновляться.
У меня на etch, lenny и сейчас на squeeze на ядре из репозитария при
синхронизации по rsync пользовательского
Dmitry Samsonov wrote:
30.09.2012 17:20, Артём Н. пишет:
1. Нормальное ли это поведение или я где-то накосячил при
конфигурировании ядра?
Передо мной никогда не стояло задачи иметь быструю отзывчивость при
высокой нагрузке на диск (слишком редко возникали подобные ситуации, ибо
нагрузка
30.09.2012 18:29, Andrei Lomov пишет:
Dmitry Samsonov wrote:
30.09.2012 17:20, Артём Н. пишет:
1. Нормальное ли это поведение или я где-то накосячил при
конфигурировании ядра?
Передо мной никогда не стояло задачи иметь быструю отзывчивость при
высокой нагрузке на диск (слишком редко
30.09.2012 18:17, Andrey Rahmatullin пишет:
On Sun, Sep 30, 2012 at 06:00:46PM +0400, Артём Н. wrote:
30.09.2012 17:55, Andrey Rahmatullin пишет:
On Sun, Sep 30, 2012 at 05:20:36PM +0400, Артём Н. wrote:
Когда что-то интенсивно работает с диском, система зависает и перестаёт
реагировать даже
On Sun, Sep 30, 2012 at 06:37:56PM +0400, Артём Н. wrote:
Когда что-то интенсивно работает с диском, система зависает и перестаёт
реагировать даже на пользовательский ввод: даже курсор не двигается.
https://bugzilla.kernel.org/show_bug.cgi?id=12309 ?
Таки нормально поведение. :-)
Так
30.09.2012 18:29, Andrei Lomov пишет:
Да, типично, когда мало RAM и всё идет в своп.
Наблюдал при пустом и даже при выключенном свопе.
--
Dmitry Samsonov
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
30.09.2012 19:11, Andrey Rahmatullin пишет:
On Sun, Sep 30, 2012 at 06:37:56PM +0400, Артём Н. wrote:
Когда что-то интенсивно работает с диском, система зависает и перестаёт
реагировать даже на пользовательский ввод: даже курсор не двигается.
https://bugzilla.kernel.org/show_bug.cgi?id=12309
30.09.2012 19:30, Dmitry Samsonov пишет:
30.09.2012 18:29, Andrei Lomov пишет:
Да, типично, когда мало RAM и всё идет в своп.
Наблюдал при пустом и даже при выключенном свопе.
Видимо, исключительно из-за обращений к ФС.
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
22 matches
Mail list logo
