История изменений
Исправление hakavlad, (текущая версия) :
они, видимо, также решили вопрос и делают лок сами, принудительно
Это можно будет проверить. Интрумент проверки готовится. Думаю ничего они не решили и ничего не лочат. СУБД же работают с обычными правами, а для лока нужен CAP_SYS_LOCK.
у нас проблема с поведением прикладного софта или ядра
Прикладной софт сам себя лочить не может, у него нет прав. Думаю таки проблема в ядре. Я вижу проблему в невозможности резервирования миниального объема кэша файлов - чтоб он не выкидывался при своппинге и при нехватке памяти.
Бешеный io при нехватке памяти, даже когда ничего не происходит - очевдно, это проблема ядра.
Исправление hakavlad, :
они, видимо, также решили вопрос и делают лок сами, принудительно
Это можно будет проверить. Интрумент проверки готовится. Думаю ничего они не решили и ничего не лочат. СУБД же работают с обычными правами, а для лока нужен CAP_SYS_LOCK.
у нас проблема с поведением прикладного софта или ядра
Прикладной софт сам себя лочить не может, у него нет прав. Думаю таки проблема в ядре. Я виже проблему в невозможности резервирования миниального объема кэша файлов - чтоб он не выкидывался при своппинге и при нехватке памяти.
Бешеный io при нехватке памяти, даже когда ничего не происходит - очевдно, это проблема ядра.
Исходная версия hakavlad, :
они, видимо, также решили вопрос и делают лок сами, принудительно
Это можно будет проверить. Интстпумент проверки готовится. Думаю ничего они не решили и ничеголочат. СУБД же работают с обычными правами, а для лока нужен CAP_SYS_LOCK.
у нас проблема с поведением прикладного софта или ядра
Прикладной софт сам себя лочить не может, у него нет прав. Думаю таки проблема в ядре. Я виже проблему в невозможности резервирования миниального объема кэша файлов - чтоб он не выкидывался при своппинге и при нехватке памяти.
Бешеный io при нехватке памяти, даже когда ничего не происходит - очевдно, это проблема ядра.