>[оверквотинг удален]
>> а Одминистратор - которому напели баек и в которые он поверил.
> Несдержанность - удел вьюношей. К слову, я как раз-таки системный программист, и
> прекрасно представляю, о чем идет речь. ARC имеет преимущество только перед
> ядрами младше 2.6.26, в 2.6.26 (или в 2.6.25 - точно не
> помню) реализовали механизм Split LRU, который, в общем-то, и есть примерно
> то же самое, что применяется в ARC, только без изменения самого
> механизма замены страниц.
> У ARC три проблемы:
> 1. ARC плохо работает (сильно нагружает систему) с малыми объемами кэша. Это
> проистекает из проблемы (2).

Свист. Вот конфига со специально ограниченным объемом ARC (ибо нефиг дважды кэшировать кэширующее приложение):

root @ hostname / # arc_summary.pl
System Memory:
         Physical RAM:  4087 MB
         Free Memory :  421 MB
         LotsFree:      63 MB

ZFS Tunables (/etc/system):
         set zfs:zfs_arc_max=1073741824
         set zfs:zfs_immediate_write_sz=1000000000
         set zfs:zvol_immediate_write_sz=1000000000

ARC Size:
         Current Size:             549 MB (arcsize)
         Target Size (Adaptive):   550 MB (c)
         Min Size (Hard Limit):    128 MB (zfs_arc_min)
         Max Size (Hard Limit):    1024 MB (zfs_arc_max)

ARC Size Breakdown:
         Most Recently Used Cache Size:          25%    138 MB (p)
         Most Frequently Used Cache Size:        74%    412 MB (c-p)

ARC Efficency:
         Cache Access Total:             280931200
         Cache Hit Ratio:      60%       169987501      [Defined State for buffer]
         Cache Miss Ratio:     39%       110943699      [Undefined State for Buffer]
         REAL Hit Ratio:       55%       155276719      [MRU/MFU Hits Only]

         Data Demand   Efficiency:    78%
         Data Prefetch Efficiency:     8%

        CACHE HITS BY CACHE LIST:
          Anon:                        0%        551949                 [ New Customer, First Cache Hit ]
          Most Recently Used:         56%        96231400 (mru)         [ Return Customer ]
          Most Frequently Used:       34%        59045319 (mfu)         [ Frequent Customer ]
          Most Recently Used Ghost:    4%        7615752 (mru_ghost)    [ Return Customer Evicted, Now Back ]
          Most Frequently Used Ghost:  3%        6543081 (mfu_ghost)    [ Frequent Customer Evicted, Now Back ]
        CACHE HITS BY DATA TYPE:
          Demand Data:                56%        95663016
          Prefetch Data:               3%        6607943
          Demand Metadata:            35%        59611727
          Prefetch Metadata:           4%        8104815
        CACHE MISSES BY DATA TYPE:
          Demand Data:                23%        26362489
          Prefetch Data:              60%        67203256
          Demand Metadata:            10%        11923431
          Prefetch Metadata:           4%        5454523
---------------------------------------------

Top:
====
load averages:  0.00,  0.01,  0.01;               up 25+14:24:52       00:26:05
242 processes: 241 sleeping, 1 on cpu
CPU states: 99.8% idle,  0.0% user,  0.2% kernel,  0.0% iowait,  0.0% swap
Kernel: 460 ctxsw, 22 trap, 667 intr, 1299 syscall, 22 flt
Memory: 4095M phys mem, 422M free mem, 4096M total swap, 4069M free swap

   PID USERNAME LWP PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
19933 root       1  54    0 2528K 1664K cpu/0    0:00  0.07% top
11560 root       1  59    0  734M  726M sleep   33:06  0.03% squid
    10 root      13  59    0   12M 7324K sleep    0:12  0.00% svc.startd
11756 squid      1  59    0 2904K 1284K sleep    0:59  0.00% diskd-daemon
   953 root       1 100  -20 2608K 1328K sleep    1:02  0.00% xntpd
11754 squid      1  59    0 2904K 1292K sleep    0:57  0.00% diskd-daemon
11757 squid      1  59    0 2904K 1300K sleep    0:55  0.00% diskd-daemon
11755 squid      1  59    0 2904K 1304K sleep    0:58  0.00% diskd-daemon
33310 squid      1  59    0 9608K 2732K sleep    0:40  0.00% httpd
   773 root       1  59    0 1468K  720K sleep    0:03  0.00% utmpd
   441 root       1  59    0    0K    0K sleep    0:22  0.00% ipmon
52753 clamav     2  59    0  422M  288M sleep  222:00  0.00% clamd
    12 root      14  59    0   11M 9144K sleep    0:19  0.00% svc.configd
    97 root       9  59    0 3896K 1624K sleep    0:12  0.00% devfsadm
   779 root      19  59    0   19M 7004K sleep    0:10  0.00% fmd

Покажь, плз, сильную нагрузку как следствие урезанного ARC?

> 2. Алгоритм замены в ARC таков, что под высоким давлением на кэш
> работает крайне неэффективно. Это порождает проблему (1). Eviction страниц может занимать
> очень приличное время.

Выше - покажь? Кэш уменьшен и на него сильное давление. Это так-то весьма нагруженный прокси.

> 3. Алгоритм замены страниц покрыт патентом IBM. В связи с чем использовать
> в приложениях можно только на страх и риск.

Пруфа, как я понимаю, не будет?

>[оверквотинг удален]
>> просто страницы с данными находятся одновременно в ARC и LRU кэше
> Пруф в студию - большинство "пейсателей" этот момент обходят стороной во всех
> презентациях и статьях. "Забывают", видимо.
>> А доп расходы по памяти это немного другое, это куча служебных структур
>> - для того что бы держать COW и версионные изменения.
> Почему этих расходов нет у BTRFS, при сходной (и более высокой) производительности?
> Архитектура, дружище, архитектура.
>> кроме того у него очень затянутый комит изменений на диск -
>> И это никак не связано с ARC кэшем который там внутри...
> Взаимоисключающие параграфы.

У тебя заявления с практикой как-то не вяжутся. И, да - система, с которой я приводил данные - Солярис:

root @ hostname / # uname -a
SunOS hostname 5.10 Generic_147441-15 i86pc i386 i86pc Solaris