افتقدت المنتدى في الأيام الفائتــة.
هل الوضع مستببٌ الآن؟
عبدالـلـه،،،
عرض للطباعة
افتقدت المنتدى في الأيام الفائتــة.
هل الوضع مستببٌ الآن؟
عبدالـلـه،،،
حيا الله ابو عابد ، استاذنا الكبير :)
الوضع الحين نوعا ما ممتاز...
كان فيه اكثر من مشكلة بعد ما نقلنا للسيرفرات الجديدة بحطها با اختصار لعلها تكون باب للنقاش.
اولا مواصفات السيرفرات.
1 - ويب سيرفر
* دوال اوبتيرون 1.6 X86_64 مع 1 ميجا كاش مموري لكل سي بي يو..
* 2 جيجا رام ECC
* IDE HD :أفكر: للاسف خيار تركيب سكازي ماكان متاح لنا (بوضح تحت)
2- MySQL Server
* دوال اوبتيرون 1.6 X86_64 مع 1 ميجا كاش مموري لكل سي بي يو..
* 3 جيجا رام ECC
* IDE HD
الـ OS :
Fedora Core 1 X86_64
طبعا السيرفرين مشبوكة بكروس كيبل داحل LAN
=======================================
اول مشكلة واجهتها بالسيرفرات كانت بالويب سيرفر.
الويب سيرفر هو برضه ال MailServer
مركبين Exim ،، لسبب ما كان فيه مشكلة بال MySQL سيرفر وكان كل ما يطفي الماي اس كيو ال والزوار يحاولون يتصفحون المنتدى يحاول برنامج المنتدى يرسل ايميل لي انه الماي اس كيو ال داون، وبما انه عدد الزوار يوميا فوق 80 الف زائر، فتخيل الظغط اللي صار على ال Exim
المهم ال Exim كان اول ما يطيح السيرفر حق ال MySQL يبدء يرسل ايميلات بعد تقريبا دقائق يبدء ال Exim يستعلك مموري بشكل مهول لدرجة انه استعلك كل المموري + كل ال سواب مموري اللي هو 2 جيجا كمان في وقت قياسي (في 10 دقائق تقريبا يكون خلص على المموري كلها)
هذا جزء من ملف اللوج /var/log/messeges
كود:ailed (gfp=0x1d2/0)
Jul 30 00:26:54 montada-web kernel: __alloc_pages: 0-order allocation failed (gfp=0xf0/0)
Jul 30 00:26:55 montada-web kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jul 30 00:27:22 montada-web kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jul 30 00:27:22 montada-web kernel: VM: killing process exim
Jul 30 00:27:24 montada-web kernel: VM: killing process exim
Jul 30 00:28:23 montada-web kernel: VM: killing process exim
Jul 30 00:30:00 montada-web kernel: __alloc_pages: 0-order allocation failed (gfp=0xf0/0)
Jul 30 00:30:02 montada-web kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jul 30 00:30:47 montada-web kernel: __alloc_pages: 0-order allocation failed (gfp=0xf0/0)
Jul 30 00:30:50 montada-web kernel: __alloc_pages: 0-order allocation failed (gfp=0xf0/0)
وهذا التوب من الويب سيرفر:
كود:00:29:55 up 1 day, 5:23, 3 users, load average: 10.72, 14.33, 10.46
464 processes: 445 sleeping, 17 running, 2 zombie, 0 stopped
CPU states: cpu user nice system irq softirq iowait idle
total 0.0% 0.0% 199.8% 0.0% 0.0% 0.0% 0.0%
cpu00 0.0% 0.0% 99.9% 0.0% 0.0% 0.0% 0.0%
cpu01 0.0% 0.0% 100.0% 0.0% 0.0% 0.0% 0.0%
Mem: 2046072k av, 2035220k used, 10852k free, 0k shrd, 1800k buff
112336k active, 1819904k inactive
Swap: 2047712k av, 2047644k used, 68k free 9476k cached
المهم.. انحلت المشكلة بتغيير ال RPM حق Exim والسبب انه ال Rpm اللي كان مركب ما كان حق ال X86_64
مع انه في ال FTP حق فيدورا اللي محطوط هناك هو فعلا حق ال X86_64
المشكلة الثانية (و مازالت قائمة) هي في الـ ncurses RPM
نفس الشي ال ncurses ماهي 100% شغالة تمام في بيئة X86_64
عموما ماهي مشكلة كبيرة.. احتاج ال ار بي ام هذي لمى اسوي كومبايل لل اباتشي وال php استخدمها في سكربت يسهل عملية الكونفيق والخيارات..
الان المشكلة الرئيسية اللي سببت بتوقف المنتدى:
المشكلة كانت في ال MySQL Server
المشكلة با اختصار انه ال MySQL دروب للكونكشن اللي مر عليها وقت معين واللي ماعاد لها داعي.
يعني اي كونكشن صار الان بيقعد اكتف كونكشن الى ماشاء الله، وهذا طبعا خطير لانه في ظرف ساعات ال Max Connections بيوصل للحد الاعلى.
رغم اني عامل اوبتمايز للماس اس كيو ال ومحدد الويب تايم اوت الى انه ال MySQL ماعمره استخدم الويت تايم اوت اللي عرفته.
المهم.. اللي اكتشفته انه connect_timeout طلع الرقم بالدقائق وليس بالثواني..كود:set-variable = wait_timeout = 15
set-variable = connect_timeout = 10
set-variable = max_connect_errors = 10
مع انه حسب موقع mysql.com الفاريبل هذا connect_timeout بالثواني.
وبكذا انحلت اول مشكلة..
المشكلة الثانية هي ال RPM حق ال V4 للـ MySQL الاصدار الخاص بـ X86_64
ال ار بي ام هذا مستحيل يعمل انستول في فيدورا كور1
طبعا اللي شغالين عليه بالمنتدى الان هو V3
بعد بحث وجدت فعلا في ناس عندهم نفس المشكلة، ال X86-64 فرجن من ماس اس كيو ال 4 فيها مشاكلكود:[root@montada-mysql V4]# ll
total 36076
-rw-r--r-- 1 root root 2630130 Jul 30 19:16 MySQL-client-4.0.20-0.x86_64.rpm
-rw-r--r-- 1 root root 7311796 Jul 30 19:16 MySQL-devel-4.0.20-0.x86_64.rpm
-rw-r--r-- 1 root root 15948944 Jul 30 19:16 MySQL-embedded-4.0.20-0.x86_64.rpm
-rw-r--r-- 1 root root 10395994 Jul 30 19:16 MySQL-server-4.0.20-0.x86_64.rpm
-rw-r--r-- 1 root root 584845 Jul 30 19:16 MySQL-shared-4.0.20-0.x86_64.rpm
[root@montada-mysql V4]# rpm -ivh *
warning: MySQL-client-4.0.20-0.x86_64.rpm: V3 DSA signature: NOKEY, key ID 5072e1f5
Preparing... ########################################### [100%]
1:MySQL-devel ########################################### [ 20%]
2:MySQL-client ########################################### [ 40%]
3:MySQL-embedded ########################################### [ 60%]
4:MySQL-server ########################################### [ 80%]
Preparing db table
Preparing host table
Preparing user table
Preparing func table
Preparing tables_priv table
Preparing columns_priv table
Installing all prepared tables
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
http://bugs.mysql.com/bug.php?id=4549
http://www.redhat.com/archives/fedor.../msg00002.html
طبعا مافيه حل متوفر,, لذى الان شغالين على V3
طبعا لحد يقول لي شيل فيدورا وركب RH9.0 مثلا...
أحتاج OS supporting 64 Bit CPU وحسب ما سمعت انه RHEL برضه يعاني من نفس المشكلة..