این مطلب ارسال شده است در روز جمعه, مهر ۱۷م, ۱۳۸۸ و در ساعت ۴:۲۶:۱۵ تحت دسته رایانه. شما می توانید نظرات این مطلب را با استفاده از RSS 2.0 خوراک دنبال کنید. همچنین می توانید نظر بدهید یا، بازتاب از سایت خود ارسال کنید.
گنجه
# tail -f /var/log/experience
همون طور که احتمالاً میدونید dpkg توساخت0 مدیریت بستهها1 در Debian است. یعنی APT و Synaptic و Aptitude و … همه روی dpkg بنا شده اند.
dpkg برای نگهداری بعضی اطلاعات بستههای نصبشده، از تعداد زیادی (برای من حدود ۹۰۰۰ تا) پروندهٔ2 کوچک توی مسیر /var/lib/dpkg/info استفاده میکنه. هر بار که بستهای رو نصب یا حذف میکنید dpkg همهٔ اون پروندهها رو از روی لوح3 میخونه. این کار روی سامانهٔ پروندهٔ4 مورد استفادهٔ من، که Ext4 هست، اولین بار بیست-سی ثانیهای طول میکشه، که برای من مدت زیادی هست. این کار در دفعات بعدی به علت قرار گرفتن همهٔ اون پروندهها در نهانگاه5 سامانهٔ پرونده در حافظهٔ اصلی، بسیار سریعتر انجام میشه، تا وقتی که دوباره از نهانگاه خارج بشند.
این مشکل هر از گاهی یک سیخی بهم میزد و روی اعصابم راه میرفت. فکرهای مختلفی برای حلش به ذهنم رسید. از بسیار پیچیده، مثل طراحی و پیادهسازی مجدد dpkg روی Tokyo Cabinet یا SQLite، تا بسیار ساده:
شاید بدونید که سامانهٔ پروندهٔ ReiserFS در کار با پروندههای کوچک بسیار عالی عمل میکنه. علتش هم استفاده از فن «تهچِپانی»6 است.7 فکر کردم شاید اگر پوشهٔ /var/lib/dpkg/info رو توی ReiserFS نگه دارم، مشکل حل بشه. این کار رو کردم، ولی به خاطر کارکرد8 داخلی dpkg روی کل /var/lib/dpkg:
$ sudo su - # cd /var/lib # tar cpzf dpkg.tar.gz dpkg # dd if=/dev/zero of=dpkg.reiserfs bs=$((256*1024*1024)) count=1 # mkreiserfs -f dpkg.reiserfs # mount -oloop dpkg.reiserfs dpkg # tar xpf dpkg.tar.gz
و بعد آزمودن و دائمی کردن با افزودن به fstab:
# echo 3 >/proc/sys/vm/drop_caches # apt-get install hello # apt-get purge hello # echo /var/lib/dpkg.reiserfs /var/lib/dpkg reiserfs loop,noatime 0 1 >>/etc/fstab
فکره جواب داد و سرعت dpkg بسیار بهتر شد. حالا حتی اولین بار هم dpkg اون کار رو در دو-سه ثانیه انجام میده.
علاوه بر مهارت ReiserFS در کار با پروندههای کوچک، چند نکتهٔ دیگه هم قابل ذکر هست. یکی این که Ext4 به علت فن «حوزه»9 در کار با پروندههای نسبتاً بزرگی که یکجا تخصیص10 مییابند بسیار سریع هست. برای همین به dd گفتم که کل پرونده رو یکجا بسازه.
از طرفی چون، در نتیجهٔ نکتهٔ قبل، کل پروندههای مربوط به dpkg روی لوح نزدیک به هم قرار میگیرند و پراکنده نیستند، با خونده شدن یک پرونده از اون حوالی، تعداد زیادی از بقیهشون هم توی نهانگاه لوح و تعدادی هم توی نهانگاه سامانهٔ پرونده قرار میگیرند. همین امر باعث میشه کلی زمان جویش11 که قبلاً برای رسیدن به پرندههای پراکنده در اطراف و اکناف لوح هدر میرفت، صرفهجویی بشه.
به گزینهٔ12 noatime در fstab هم دقت کنید. رفتار معمولی سامانههای پرونده این هست که در هر دسترسی (اعم از خواندن یا نوشتن) به یک پرونده، زمان دسترسی رو ذخیره میکنند. این خیلی بده! هر دسترسی = حداقل یک عمل نوشتن روی لوح، و عمل نوشتن هم معمولاً کندتر از خوندن هست. نکته این جاست که برنامههای رایج امروزی معمولاً روی اون زمان ثبتشده برای آخرین دسترسی حساب نمیکنند و عملاً اون عدد بیاستفاده است! گزینهٔ noatime به سامانهٔ پرونده میگه که کلاً قید ثبت اون زمان رو بزنه و به این ترتیب کلی عمل نوشتن صرفهجویی کنه.
- Back-end [↩]
- Package management [↩]
- File [↩]
- Disk [↩]
- File system [↩]
- Cache [↩]
- Tail packing [↩]
- http://en.wikipedia.org/wiki/ReiserFS#Performance [↩]
- Mechanism [↩]
- Extent [↩]
- Allocation [↩]
- Seek [↩]
- Option [↩]
مهر ۲۳م, ۱۳۸۸ at ۲:۱۳:۱۱
خب چرا از اين همه پرونده براي نگهداري اطلاعات استفاده ميكنه، نميشه همهي اطلاعات رو در يك پرونده جمع آوري كنه؟
پاسخ
ابراهیم پاسخ:
مهر ۲۳م, ۱۳۸۸ در ۳:۰۲:۵۷
به نظر من هم میشد dpkg رو بهتر از این طراحی کرد. با این حال طراحان dpkg هم دلایل خودشون رو برای این تصمیم دارند. مثلاً توی یک بحث در همین زمینهها دیدم که یکی از ریشسفیدهای dpkg میگفت چون dpkg تقریباً پایینترین قسمت سیستم نرمافزاری (مقصود، در فضای کاربر (user-space) ) هست، نباید به یک کد بزرگ و پیچیده مثل یک موتور SQL (اشارهاش به SQLite بود) وابستهاش کرد. از طرفی این دوستان تعصب خاصی روی این دارند که پروندهها تماماً متن ساده باشند تا بشه دستی هم ویرایششون کرد!
پاسخ
آذر ۲م, ۱۳۸۸ at ۱۸:۱۸:۲۷
خیلی خیلی مفید بود.
کلی چیز یاد گرفتم.
ممنون
پاسخ