Мога ли да накарам алармите fcntl и Perl да си сътрудничат?

Аз съм на linux, nfs, с много включени машини.

Опитвам се да използвам fcntl за прилагане на заключване на файлове. Използвах flock, докато не открих, че работи само между процеси на една и съща машина.

Сега, когато извикам fcntl с F_SETLKW, perl алармите (за добавяне на таймаут) не работят както преди. Това обикновено би било добре, но ctrl-c също не работи наистина.

Това, което вярвам, че се случва, е, че fcntl проверява за сигнали само на всеки 30 секунди или така. Алармата се връща в крайна сметка. Ctrl-c се хваща... в крайна сметка.

Има ли нещо, което мога да направя, за да коригирам честотата, с която fcntl проверява за тези сигнали?


nfs locking perl fcntl
person mmccoo    schedule 23.09.2010    source източник
comment
Заключването на NFS е трудно. Използването на File::NFSLock вероятно ще ви даде решение, което просто работи, без да се налага да пишете никакъв код.   -  person rafl    schedule 23.09.2010
comment
File::NFSLock има някои собствени дупки. Опитва се да изиграе някои трикове с твърди връзки и други неща, но ако вашата файлова система е претоварена, можете лесно да имате условия на състезание, които водят до два процеса с едно и също заключване.   -  person mmccoo    schedule 24.09.2010
comment
Той наистина има някои документирани недостатъци, включително тенденцията да спира процесите на изчакване в силно спорна ситуация, да. Въпреки това, за проблема, който се опитвате да разрешите, той все още може да бъде правилният компромис. Не мога да кажа точно, тъй като не описахте по-подробно обстоятелствата си. Мога обаче да говоря от опит с използването на File::NFSLock: Никога не съм виждал неговия подход да пречи на някой от моите процеси, дори в ситуации с много спорове, в сравнение с повечето други неща, които правя. Броят на модулите в зависимост от него също изглежда показва, че е достатъчно добър за повечето хора   -  person rafl    schedule 24.09.2010
comment
@rafl: моля, публикувайте нещо като отговор. хората имат нужда от нещо, което да +1. @mmccoo: не очаквайте чудеса, заключването на файлове в NFS по дефиниция е нарушено и не може да се разчита на него. Независимо от езика за програмиране. Най-общо казано, ако имате нужда от споделено заключване, време е да помислите за внедряване на истинска разпределена файлова система, напр. GlusterFS. Дайте това като намек на вашия работодател/ИТ/клиенти.   -  person Dummy00001    schedule 24.09.2010

Отговори (1)


arrow_upward
1
arrow_downward

Определено не съм експерт по въпроса, но знам, че fcntl, както също казахте, няма да работи във вашия случай. fcntl съветни ключалки имат смисъл само в рамките на една и съща машина.

Така че забравете ме, ако това не е по темата. Използвах File::NFSLock за разрешаване на проблема с кеш бури/dogpile/натискане. Имаше множество сървъри за приложения, които четат и записват кеш файлове на NFS том (не е много добра идея, но с това трябваше да започнем).

Подкласирах/опаковах File::NFSLock, за да променя поведението му. По-специално имах нужда от:

  • постоянни заключвания, които не изчезват, когато обект File::NFSLock излезе извън обхвата. Използвайки обикновен File::NFSLock, вашето заключване ще изчезне, когато обектът излезе извън обхвата. Това не беше това, от което имах нужда.
  • че действителните файлове за заключване също съдържат името на машината, която е придобила заключването. Идентификационният номер на процеса очевидно не е достатъчен, за да се реши дали процесът е прекратен, така че мога безопасно да открадна заключващия файл. Затова модифицирах кода, за да записва заключващите файлове като machine:pid вместо само pid.

Това работи чудесно от няколко години.

Докато обемът на заявките се увеличи 10 пъти. Това означава, че миналия месец започнах да изпитвам първите проблеми, при които наистина натоварен кеш файл се записваше от два бекенда едновременно по едно и също време, оставяйки мъртви заключвания. Това се случи при мен, когато достигнахме около 9-10 милиона общи показвания на страници на ден, само за да ви дам представа.

Последният счупен кеш файл изглеждаше така:

<!-- START OF CACHE FILE BY BACKEND b1 -->
... cache file contents ...
<!--   END OF CACHE FILE BY BACKEND b1 -->
... more cache file contents ... wtf ...
<!--   END OF CACHE FILE BY BACKEND b2 -->

Това може да се случи само ако два бекенда пишат в един и същ файл едновременно... Все още не е ясно дали този проблем е причинен от File::NFSLock + нашите модове или някакъв бъг в приложението.

В заключение, ако приложението ви не е много натоварено и трафикирано, изберете File::NFSLock, мисля, че това е най-добрият ви залог. Сигурни ли сте, че все още искате да използвате NFS?

person Cosimo    schedule 30.10.2010