>[оверквотинг удален]
>> а Одминистратор - которому напели баек и в которые он поверил.
> Несдержанность - удел вьюношей. К слову, я как раз-таки системный программист, и
> прекрасно представляю, о чем идет речь. 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