Ext4 такая ext4

запусти любой бенчмарк и посмотри random read speed.

я не верю бенчмаркам. Я верю скорости работы нужного приложения.

ядро-то тут причём?

ядру тоже нужна память.

вот оом и включился, и кильнул сеть. В логе об этом должна быть запись. А ты что хотел?

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

для сервера это равносильно смерти. я бы хотел чтобы он убил что-то другое, >логично? только он не убивал сеть, драйвер написал что не может увеличить >буфера и сдох.

Это в каком лине такие ужжосы ?

Это в каком лине такие ужжосы ?

в смысле? Это ядре было, следовательно во всех. Лень щас смотреть сырцы, но можно погрепать на предмет printk...

в смысле? Это ядре было, следовательно во всех. Лень щас смотреть сырцы, но >можно погрепать на предмет printk...

Вообще актуально. В каком ядре случился этот эпик феил ? И по какой маске грипать ?

Так, прогрепал всё что мог, нету там такого. Оно выделяет ресурсы при ifup и дальше, вроде как, не трогает. Т.е. если начать играться с параметрами интерфейсов когда нет памяти то может и сдохнуть. А так, вроде, должно работать. Есть ещё небольшой шанс что перепутал драйвер. Надо бы реалтеки прогрепать...

всё такое цветастое... я ничего не понял...

По ссылке у дефрагментатора две проблемы: 1) он не проверяе есть ли на фс достаточно свободного места для дефрагментации. 2) дефрагментатор блокирует фс каким то образом, по крайней мере bonnie++ валится с ошибкой: Writing intelligently...Can't write block.: No such file or directory Can't write block 30231. По идее ошибки связанны. В любом случае он не пригоден для использования на нагруженных серверах.

Так, прогрепал всё что мог, нету там такого. Оно выделяет ресурсы при ifup и >дальше, вроде как, не трогает. Т.е. если начать играться с параметрами >интерфейсов когда нет памяти то может и сдохнуть. А так, вроде, должно >работать. Есть ещё небольшой шанс что перепутал драйвер. Надо бы реалтеки >прогрепать...

Нет памяти это когда уже весь своп занят или только опера ?

а оно два типа памяти выделяет. Для dma-буферов через kmalloc, тогда ему нужен continious кусок реальной памяти. Ну и в паре мест оно выделяет через vmalloc, эта память может выпадать в своп и не обязательно физически в оперативе находится одним непрерывным куском.

В целом всё выглядит надёжно. Я даже старую версию драйвера скачал, там тоже всё, вроде, толково. Так что или у меня был не e1000, или таки что-то плохое в этот момент в системе произошло.

Кстати, по поводу kmalloc. Я вижу инструкции что его лучше дёргать сразу после старта системы, потом (теоретически) непрерывного куска нужного размера может и не оказаться.

ядру тоже нужна память.

ядро обойдётся - у ядра есть своя личная память.

для сервера это равносильно смерти.

никто не спорит.

я бы хотел чтобы он убил что-то другое, логично?

а я хочу пива. Логично? Но во первых, за пивом надо идти, во вторых на работе не пью.

только он не убивал сеть, драйвер написал что не может увеличить буфера и сдох.

У ООМ есть набор очень неплохих эмпирик - он следит за приложениями, стараясь вычислить виновника, который виноват в том, что памяти нет. Я читал мануали и дискуссии разрабов, потому примерно представляю КАК это работает. Суть в том, что ядро выделяет _виртуальную_ память, которой _нет_. Вот например мой ФФ сейчас выделил 422Мб из 384Мб возможных (своп есть, но он пустой). Потому ядро не может проконтролировать память при выделении. Ну не может, и всё. Смирись. Однако, не вся выделенная память используется - у меня сейчас свободно 180Мб памяти, которая используется как дисковый кеш. В какой-то трагичный момент времени происходит СТРАШНОЕ - приложение занимает свою выделенную ячейку, а её НЕТ. Какое это будет приложение? Неизвестно. Надо его убивать? Конечно НЕТ! Вполне вероятно, что это очень нужное, и критическое приложение. И что делать? Вот именно в этот СТРАШНЫЙ момент и приходит ООМ, он просматривает, какие приложения как жрали память, пытаясь эмпирически определить виновника - скорее всего, это просто какой-то глюк, и утечка в каком-то приложении. Одна из эмпирик - поиск приложений, которые выделяют куски памяти по N байт, но их не возвращают. Скорее всего программист написал цикл, в начале которого память выделяется, а освободить её он тупо забыл. Такое приложение и будет убито. Есть и другие эмпирики, намного более сложные. За каждую эмпирику каждому приложению зачисляется определённый скор (score), и то приложение, которое набрало больше всего скора, безжалостно выпиливается. Отчёт об этом можно почитать в логе (grep /var/log/syslog в слаке).

Но в твоём случае ООМа видимо не было вообще, если ты действительно говоришь за память ядра. Это какие-то драйверопроблемы, возможно твой драйвер несовместим с каким-то «улучшающим» патчем. Может разраб патча почему-то решил, что N байтов для буфера - жирно, и сделал M, а разраб драйвера смотрел на ванильный код, и думал, что будет N. Вот места и не хватило. Пиши багрепорт маинтейнеру, пусть либо обратно патчит ядро, либо пусть пишет патч к драйверу. К ООМ это не относится.

в смысле? Это ядре было, следовательно во всех.

та не гони - ещё скажи, что у тебя ваниль.

По ссылке у дефрагментатора две проблемы: 1) он не проверяе есть ли на фс достаточно свободного места для дефрагментации. 2) дефрагментатор блокирует фс каким то образом, по крайней мере bonnie++ валится с ошибкой: Writing intelligently...Can't write block.: No such file or directory Can't write block 30231. По идее ошибки связанны. В любом случае он не пригоден для использования на нагруженных серверах.

теперь понял, почему я считаю все дефрагментаторы наколенными поделками, негодными для продакшена? А единственный годный: fs->tar->backup->mkfs->tar

Кстати, по поводу kmalloc. Я вижу инструкции что его лучше дёргать сразу после старта системы, потом (теоретически) непрерывного куска нужного размера может и не оказаться.

да. так и есть. потому иногда демон не получается рестартовать. Только перезагрузка помогает.

да. так и есть. потому иногда демон не получается рестартовать. Только >перезагрузка помогает.

linux как и windows лечится перегрузками и переустановками :-))) ...

linux как и windows лечится перегрузками и переустановками

разница есть - в linux'е это происходит при аварии. Нехватка памяти ядра == авария. И связана она либо с аппаратным сбоем, либо с кривым ядром (кривыми могут быть не только сами ядра, но и модули. Ну и не надо забывать о патчах, которые накладывают все, кому не лень)

разница есть - в linux'е это происходит при аварии.

В виндовсе тоже при аварии но учитывая уровень пользователей виндовс там аварии чаще :)))

Нехватка памяти ядра == авария. И связана она либо с аппаратным сбоем, либо с >кривым ядром (кривыми могут быть не только сами ядра, но и модули. Ну и не >надо забывать о патчах, которые накладывают все, кому не лень)

Какой ужжос :)))

Какой ужжос :)))

ну если это твой недобук, то хрен с ним. Если это сервер, за простой которого снимают С ТЕБЯ деньги...

иногда демон не получается рестартовать.

какой демон? Я вообще такой ситуации не встречал. Возможно, на amd64 с этим проще в силу того что там памяти под ведро больше

какой демон?

да я сам не в курсе. может pppd если пованговать... Ну что-бы сеть передёрнуть.

Запускал test_fs_ubuntu.sh из https://github.com/nagual2/Test даже на рейде тест всех фс занял 8 часов. btrfs как всегда слила:

Writing intelligently...Can't write block.: No space left on device

Может кто нибудь подскажет как жестко задать размер журнала или какие там нужны ограничения ?

Перед нами Ubuntu Server 12.04.1 LTS 64 bit

Во время тестирования в логе было:

WARNING: at /build/buildd/linux-3.2.0/fs/btrfs/extent-tree.c:5985 use_block_rsv+0x17c/0x190 [btrfs]() Hardware name: VMware Virtual Platform Modules linked in: btrfs zlib_deflate libcrc32c ext2 vmhgfs(O) vsock(O) acpiphp ppdev vmci(O) vmw_balloon psmouse snd_ens1371 gameport snd_rawmidi snd_seq_device serio Pid: 4244, comm: umount Tainted: G O 3.2.0-29-generic #46-Ubuntu Call Trace: [<ffffffff81066cff>] warn_slowpath_common+0x7f/0xc0 [<ffffffff81066d5a>] warn_slowpath_null+0x1a/0x20 [<ffffffffa01c862c>] use_block_rsv+0x17c/0x190 [btrfs] [<ffffffffa0215b38>] ? update_existing_ref.isra.6+0xc8/0x170 [btrfs] [<ffffffffa01cb3fd>] btrfs_alloc_free_block+0x3d/0x200 [btrfs] [<ffffffff81161ebb>] ? kfree+0x3b/0x140 [<ffffffffa01fab8a>] ? read_extent_buffer+0xea/0x180 [btrfs] [<ffffffffa01ba122>] __btrfs_cow_block+0x122/0x430 [btrfs] [<ffffffffa01ba526>] btrfs_cow_block+0xf6/0x220 [btrfs] [<ffffffffa0209053>] ? btrfs_set_lock_blocking_rw+0x43/0xb0 [btrfs] [<ffffffffa01be23a>] btrfs_search_slot+0x34a/0x710 [btrfs] [<ffffffffa01d028a>] btrfs_del_csums+0x17a/0x2f0 [btrfs] [<ffffffffa01c5dce>] __btrfs_free_extent+0x45e/0x650 [btrfs] [<ffffffffa01c6210>] run_delayed_data_ref+0xb0/0x1a0 [btrfs] [<ffffffffa01c9d1e>] run_one_delayed_ref+0x8e/0xf0 [btrfs] [<ffffffffa01c9e54>] run_clustered_refs+0xd4/0x240 [btrfs] [<ffffffffa01ca08a>] btrfs_run_delayed_refs+0xca/0x220 [btrfs] [<ffffffff816583dd>] ? mutex_lock+0x1d/0x50 [<ffffffffa01f42e6>] ? btrfs_run_ordered_operations+0x1d6/0x1f0 [btrfs] [<ffffffffa01da163>] btrfs_commit_transaction+0x93/0x840 [btrfs] [<ffffffff8108aa50>] ? add_wait_queue+0x60/0x60 [<ffffffffa01b523c>] btrfs_sync_fs+0x6c/0xf0 [btrfs] [<ffffffff811a6493>] __sync_filesystem+0x63/0x90 [<ffffffff811a653b>] sync_filesystem+0x4b/0x70 [<ffffffff81179aeb>] generic_shutdown_super+0x3b/0xe0 [<ffffffff81179c26>] kill_anon_super+0x16/0x30 [<ffffffff8117a26c>] deactivate_locked_super+0x3c/0xa0 [<ffffffff8117aaee>] deactivate_super+0x4e/0x70 [<ffffffff8119715d>] mntput_no_expire+0x9d/0xf0 [<ffffffff8119848b>] sys_umount+0x5b/0xd0 [<ffffffff81661ec2>] system_call_fastpath+0x16/0x1b ---[ end trace 56dc0b99ee8f18aa ]--- btrfs: block rsv returned -28

Может кто нибудь подскажет как жестко задать размер журнала или какие там нужны ограничения ?

man tune2fs

       -J journal-options
              Override the default ext3 journal parameters. Journal options are comma separated, and may take  an
              argument using the equals ('=')  sign.  The following journal options are supported:

                   size=journal-size
                          Create a journal stored in the filesystem of size journal-size megabytes.   The size of
                          the journal must be at least 1024 filesystem blocks (i.e., 1MB if using 1k blocks,  4MB
                          if  using  4k  blocks, etc.)  and may be no more than 102,400 filesystem blocks.  There
                          must be enough free space in the filesystem to create a journal of that size.

                   device=external-journal
                          Attach the filesystem to the journal block device  located  on  external-journal.   The
                          external journal must have been already created using the command

                          mke2fs -O journal_dev external-journal

                          Note  that  external-journal  must be formatted with the same block size as filesystems
                          which will be using it.  In addition, while there is  support  for  attaching  multiple
                          filesystems  to  a  single external journal, the Linux kernel and e2fsck(8) do not cur‐
                          rently support shared external journals yet.

                          Instead of specifying a device name directly, external-journal can also be specified by
                          either  LABEL=label  or  UUID=UUID  to locate the external journal by either the volume
                          label or UUID stored in  the  ext2  superblock  at  the  start  of  the  journal.   Use
                          dumpe2fs(8)  to  display  a  journal  device's  volume label and UUID.  See also the -L
                          option of tune2fs(8).

WARNING: at /build/buildd/linux-3.2.0/fs/btrfs/extent-tree.c:5985

man LORCODE

Can't write block.: No space left on devi

блин, что-то уж больно часто это мелькает... Похоже и правда нездоровая фигня. Ээх, а я так надеялся что будет «свой» zfs с плясками и танцами.

man tune2fs

Катит далеко не для всех фс man tune2fs ...

блин, что-то уж больно часто это мелькает... Похоже и правда нездоровая фигня. >Ээх, а я так надеялся что будет «свой» zfs с плясками и танцами.

ZFS=RAID+LVM+BTRFS+пляски+танцы+бубен+арфа+барабан.

:-))))