پاک کردن هم زمان رکوردها توسط bc_cleanup از روی چند hard

 یکی از اشکالاتی که در bc_cleanup هست اینه که رکوردهای قدیمی‌تر رو به صورت sequential از روی چند هارد پاک میکنه. یعنی اول میره سراغ هارد اول، بعد که کارش تموم شد میره سراغ هارد دوم و به همین ترتیب. این باعث میشه اگر به هر دلیل پاک کردن رکوردها از هارد اول طول بکشه هاردهای دیگه پر بشن و کسی نباشه به دادشون برسه. برای رفع این مشکل راهی که اندیشیدم multi-thread کردن bc_cleanup بود. الان وقتی bc_cleanup با سوییچهای ‎-np یا ‎-ds که اولی برای وقتی است که میخواهیم not paired events پاک بشن و دومی برای وقتی است که میخواهیم رکوردهای قدیمی‌تر برای cleanup شدن disk space پاک بشن صدا زده میشه این کار به صورت هم زمان توسط threadهای مختلف انجام میشه.

یک اشکالی که این وسط هست که امیدوارم در محیط مشتری باعث بروز مشکل نشه اینه که اگر پاک کردن رکوردها از روی هاردی طول بکشه، به هر دلیل، مثل اینکه تعداد رکوردهای اون هارد خیلی بیشتر از هاردهای دیگه باشه، این باعث میشه از bc_cleanup تا تکمیل این پاک شدن خارج نشیم. با مثال بریم جلو مطلب بهتر روشن شه. مثلاً یه هاردی تعداد رکوردهای خیلی کمی برای پاک کردن داره و کارش در عرض ۱۰ ثانیه به انجام میرسه، اما هارد دیگه‌ای تعداد خیلی زیادی رکورد برای پاک کردن داره و کارش ممکنه یک ساعت یا بیشتر طول بکشه. این باعث میشه اگر هارد اول در طول این یک ساعت پر بشه دیگه bc_cleanupی نباشه که بخواد به دادش برسه. bc_schedule میبینه bc_cleanup هنوز مشغوله، پس نمیاردش بالا. bc_cleanupی هم که بالا است کارش با هارد اول تموم شده و داره رکوردهای هارد دوم رو پاک میکنه.

برای اینکه چنین مشکلی پیش نیاد میشه فکر کرد. مثل اینکه اصولاً bc_cleanupهای مختلفی بتونیم اجرا کنیم و هر کدوم بر اساس آرگومانی که میگیرند کار مستقلی رو انجام بدند. مثلاً یکی not pairedهای هارد اول رو پاک کنه و هم زمان دیگری رکوردهای قدیمی‌تر هارد دوم رو. منتها ترجیح دادم فعلاً این پکیج بره تو محیط مشتری، بازخوردهاش دربیاد، اگر لازم شد بعد میریم سراغ یه چنین کاری. قبلاً یه بار چنین کاری رو انجام داده‌ام. یعنی زمانی np با ds هم زمان cleanup میشدند. اما بازخورد خوبی نگرفتم. باعث شد مجبور شم دوباره اونها رو به صورت سریال انجام بدم. وقتی np روی یه هارد داره انجام میشه باعث کند شدن ds روی همون هارد میشه! چرا؟ ظاهراً نباید بشه، اما میشه.

نظرات

ارسال یک نظر

پست‌های معروف از این وبلاگ

دوربین Avigilon جدید

 وقتی دوربین Avigilon اومد هیچ SDKیی همراهش نبود. نیاز بود motion رو از خود دوربین بگیریم و برای ارتباط برقرار کردن با اون تنها راه، استفاده از پروتکل Onvif بود. تقریباً یک ماه وقت گذاشتم و کلاس مستقلی برای ارتباط برقرار کردن با این دوربین نوشتم. کلاً چهار راه برای دریافت notification messageها از دوربین در دسته. از جمله اونها، چیزی که ما لازم داریم، دریافت وضعیت حرکت (motion state) است: pull point subscription policy pausable subscription manager interface بعضی از دوربینها موقعی که دارند تصویر رو به دست میدند یک data stream هم علاوه بر video stream و احیاناً audio stream حاوی اطلاعات حرکت و غیره رو با اون همراه میکنند. در مورد این دوربین روش دوم پیاده شده بود و هیچ کدی که بتونه چنین ارتباطی رو با دوربین برقرار کنه زده نشده بود. در کلاس avigilon camera این کد آماده شد و از اون به بعد تونستیم از این دوربین motion رو هم بگیریم. طبعاً اطلاعات مربوط به video stream url هم به صورت hard code در این کلاس قرار گرفت. گذشت تا نوبت به دوربین KDT رسید. این دوربین برای ارسال اطلاعات (meta data)...
بیشتر بخوانيد

مقدمه

 سلام از من خواسته شد تا پیرامون کارهایی که روی به نما انجام میدم مطلب بنویسم و به اصطلاح گزارش ارائه کنم. به نما از زمانی که توسعه‌ش فردی شد، شد یه نقاشی که بدون مزاحم با نظری متفاوت بشینم و اونطوری که دوست دارم تکمیلش کنم، بدون حذف هیچ چیزی که به نظرم برای بهبودش لازم بود، با اولویت دادنهایی که دست خودم بود. برای همین گزارش دادن برام تعریفی نداشت. اما خب چه میشه کرد؟ دنیا است و چرخش اون. گهی بر پشت زین سواری و زمانی اسبت مال دیگری میشه و مجبور میشی زینش رو به دوش بکشی. گاهی سواری و گاهی باید سواری بدی. مالک محصول بودن میتونه معانی متفاوت و بعضاً متناقضی بده. بگذریم. به نما چی هست اصلاً؟ به نما یه نرم افزار نظارت تصویریه. دوربینها و رکوردهاشون رو کنترل میکنه. فعلاً داره تو بانک پاسارگاد و چند جای دیگه مورد استفاده قرار میگیره. تا کی دووم بیاره با خدا است. اما تا هست منم با جدیت روش کار میکنم. امیدوارم عمرش دراز باشه. خیلی روش زحمت کشیدیم و حیفه از دست بره. تمام تلاش تمام ما تو این چند سال و تمام امیدهایی که بهش بسته‌ایم منو وادار میکنه با تمام وجود ازش دفاع کنم و توسعه‌ش بدم. اگه ...
بیشتر بخوانيد

تغییرات داده شده در database در ارتباط با دوربین Hikvision DS-2CD1123G0E-I

 همونطور که گفتم تغییراتی که روی sourceها و database در ارتباط با این دوربین دادم موقتی است و لازمه این دوربین به طور صحیح‌تری به به نما اضافه بشه. برای همین یک branch با نام hikvision_ds-2cd1123g0e-i ساختم تا تغییراتی که در sourceها ایجاد میکنم موقتی باشه و تو branch اصلی اعمال نشه. اما تغییراتی که در database ایجاد کردم طبعاً در database هم باقی میمونه و لازمه بعد که برگشتم سر branch اصلی و مسأله این دوربین رو حل کردم اونها رو undo کنم. برای همین به خاطر اینکه این تغییرات به طور دقیق جایی ثبت بشن اونها رو اینجا میارم: 1. ALTER TABLE `MonitorPresets` CHANGE `Type` `Type` ENUM( 'Local', 'Remote', 'File', 'Ffmpeg', 'openRTSP', 'Win4Net', 'RcpPlus', 'Grundig', 'Avigilon', 'KDT', 'HIKVISION' ) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL; 2. ALTER TABLE `Monitors` CHANGE `Type` `Type` ENUM( 'Local', 'Remote', 'File', 'Ffmpeg', 'openRTSP', 'Rcp...
بیشتر بخوانيد