ปั่นเพื่อแม่ (Bike for mom) ได้รับความสนใจเกินกว่าความคาดหมายจนล่มในช่วงแรก

ปั่นเพื่อแม่ (Bike for mom) ได้รับความสนใจเกินกว่าความคาดหมายจนล่มในช่วงแรก
ปั่นเพื่อแม่ (Bike for mom) ได้รับความสนใจเกินกว่าความคาดหมายจนล่มในช่วงแรก

ข้อความจาก thaibike.net ว่า
ผู้สนใจร่วมเป็นหนึ่งในเหตุการณ์ประวัติศาสตร์ “BIKE FOR MOM ปั่นเพื่อแม่
เพียง 15 นาทีมีผู้สนใจเข้าร่วมลงทะเบียนเป็นจำนวนมาก
ส่งผลให้เว็บไซต์มีปัญหาขัดข้อง และมีการเพิ่มเครื่องบริการอีกหลายตัวเพื่อแก้ปัญหา
ประชาชนที่สนใจเข้าร่วมกิจกรรม ในกรุงเทพ เต็มจำนวนแล้ว 40,000 คน
เช็คที่เหลือแต่ละจังหวัด ได้ที่ศาลากลางจังหวัด

https://www.youtube.com/watch?v=UDnLVEanwnM

ซึ่งผมก็จะร่วมกิจกรรมที่ลำปางด้วย ได้เข้าเว็บไซต์ http://bikemom2015.moi.go.th
หรือ http://www.bikeformom2015.com
เมื่อวันที่ 1 กรกฎาคม 2558 พบว่าหลังเปิดระบบให้ลงทะเบียนไม่กี่นาที ระบบก็ล่ม ลงทะเบียนไม่ได้
แต่ปัจจุบันลงทะเบียนได้แล้ว และเปิดไปถึง 9 สิงหาคม 2558 ปั่นร่วมกันอาทิตย์ที่ 16 สิงหาคม 2558
http://www.matichon.co.th/news_detail.php?newsid=1435733620
แล้ววันแรกพบภาพที่คุณ krisda ถ่ายจากทีวีว่าออกข่าวช่อง 3 ด้วย
โพสต์ในกลุ่ม “ลำปาง นครแห่งจักรยาน” ซึ่งการลงทะเบียนออนไลน์เป็นเพียงช่องทางหนึ่ง
อีกช่องทาง คือ การไปลงทะเบียนที่ศาลากลาง ของแต่ละจังหวัด
https://www.facebook.com/groups/723715197696029/permalink/877043582363189/
ส่วน ข่าวช่อง 7 ก็มีที่ http://news.ch7.com/detail/130336/

ที่น่าสนใจว่าเว็บไซต์ล้มนั้น หรือทำไมเว็บไซต์ช้า หรือล้ม
มีคำอธิบายวิธีป้องกันที่ blog.levelup.in.th โดยคุณ heha ซึ่งสรุปไว้ดังนี้
http://blog.levelup.in.th/2011/01/31/why-do-your-website-slow-or-crash%E0%B8%97%E0%B8%B3%E0%B9%84%E0%B8%A1%E0%B9%80%E0%B8%A7%E0%B9%87%E0%B8%9A%E0%B9%84%E0%B8%8B%E0%B8%95%E0%B9%8C%E0%B8%82%E0%B8%AD%E0%B8%87%E0%B8%84%E0%B8%B8%E0%B8%93/
Database ตอบสนองช้า
1. Database ไม่ได้ใส่ index key ต้องทำกันตั้งแต่ตอนออกแบบระบบฐานข้อมูลกันเลย
2. จำนวนคิวรี่ (Query) ต่อหน้ามีมากเกินไป ก็เป็นการออกแบบเว็บเพจ
3. เว็บไซต์ไม่มีการใช้ระบบ Cache อันนี้เป็นเรื่องการ config server
อยากรู้ว่าใช้ระบบ cache รึเปล่าใช้บริการได้ที่
https://developers.google.com/speed/pagespeed/insights/
ลองตรวจของ จังหวัดในประเทศไทยดูครับ มักพบปัญหา Leverage browser caching
เว็บไซต์ของผมก็มีปัญหา ยังไม่ได้ตามไปแก้ไขเลย
4. Table ถูก Lock บ่อย เนื่องจาก update หรือ insert บ่อย
และเปลี่ยนเป็น innodb แทน myisam เพราะ innodb จะ lock เฉพาะ row
ไม่ lock ทั้ง table จึงช่วยเรื่องความเร็วได้มาก

CPU Server ขึ้นสูง
1. Script php มีปัญหา ไม่ optimize code ให้ดี ไม่ clear ตัวแปรเมื่อเลิกใช้
วนลูปที่ไม่จำเป็น หรือสร้าง object แล้วไม่ใช้ หรือเขียน algorithm ไม่ดี
2. process กิน memory มากไป
เช็คตัวแปรต่าง ๆ และตั้งค่าให้เหมาะสม สำหรับ web server มีให้ตั้งเยอะ

Server Crash บ่อย
1. ลด MaxClients ใน apache config ลง จำกัดจำนวนผู้ใช้ ป้องกัน server ล้ม
2. ตั้งเวลา reboot เครื่อง หากมีเหตุผลที่ตอบได้ว่าจำเป็น
3. เพิ่ม max_connections ของ mysql ก็น่าจะรองรับได้เพิ่มขึ้น
4. อัพเกรดทุกอย่างที่คิดว่าน้อย เช่น cpu, memory, harddisk หรือ bandwidth

ตก/ขึ้น

ตก ขึ้น (down rise)
ตก ขึ้น (down rise)

ตก/ขึ้น

มีตก…ย่อมมีขึ้น
ดวงอาทิตย์มีขึ้น มีตก หมุนเวียนไปเป็นวัฎจักร
เมื่อพบพานเรื่องราวดีๆหรือเหตุการณ์ร้ายๆ
มองอย่างเข้าใจ ไม่ตั้งอยู่บนความประมาท
ใช้สติและปัญญา เป็นเครื่องมือต้อนรับความเปลี่ยนแปลงต่างๆ
ที่เกิดขึ้นในชีวิตอย่างสงบ และมีความสุข
http://www.tairomdham.net/index.php?topic=8326.0

จากปฏิทินตั้งโต๊ะ ธนาคารกรุงเทพ ปีพ.ศ.2556
http://www.facebook.com/media/set/?set=a.620932377920897.1073741833.506818005999002

ปัญหากับ ldap ล้มอาการใหม่ แต่วิธีแก้เหมือนเดิม

stop on swap space after ldap service
stop on swap space after ldap service

อาการขอวันนี้
1. fedora core 4 บูทไม่ขึ้นอีกแล้วหลังไฟดับ .. บูทแล้วค้าง โดยฟ้องคำว่า swap
2. reboot แล้วกด i ตามคำแนะนำ press ‘I’ to enter interactive startup
3. กดปุ่ม y เลือกบริการไปเรื่อย ๆ แล้วก็พบ ldap ผมเลือก n เพราะถ้า y ก็จะค้างอยู่ตรงนั้นอีก
4. หลังเข้าไปก็ทดสอบ start แบบ manual
พบคำว่า Checking configuration files for slapd: แล้วก็ค้างตรงนั้น
ผมต้องกดปุ่ม ctrl-c ออกมา

วิธีแก้ไข

1. สั่ง recover ด้วยคำสั่งต่อไปนี้ แต่ถ้าท่านใช้ต้องเปลี่ยนคำว่า myname
#/usr/sbin/slapd_db_recover -v -h /var/lib/ldap/myname
2. ต้องแก้ไขสิทธ์ของแฟ้ม จึงจะ start ได้สำเร็จ
โดยเข้าห้อง /var/lib/ldap/myname
แล้วสั่ง #chown ldap:ldap *
3. สั่ง #/etc/init.d/ldap start
หรือ #/etc/init.d/ldap status พบว่ามาบริการเหมือนเดิม

press 'I' to enter interactive startup
press 'I' to enter interactive startup

http://www.thaiall.com/blog/burin/4571/

ldap ในเครื่องบริการ .. ไม่ตื่นอีกแล้ว

ldap fail
ldap fail

ขั้นตอนการตรวจสอบ และแก้ไข
ในกรณี ldap server ล้มหลังไฟฟ้าดับ แล้ว ldap server ก็ตอบว่า ldap unbind

1. พบว่าสั่ง start บริการ ไม่สำเร็จ
#/etc/init.d/ldap start
Checking configuration files for slapd: [FAILED]
2. แก้ไขปัญหาด้วยการ recover
#/usr/sbin/slapd_db_recover -v -h /var/lib/ldap/myname
ได้แฟ้ม log.0000000001 มาใหม่ และดูเหมือน recover สำเร็จ
แต่ก็ยังใช้งานไม่ได้ จึง restart เครื่อง เพื่อล้างค่าต่าง ๆ
3. restart เครื่องคอมพิวเตอร์
4. เมื่อสั่ง start บริการ ก็พบคำว่า OK
สั่ง start กี่ครั้ง ก็ตอบว่า OK .. หมายความว่าไม่ OK
เมื่อตรวจดู status ก็พบว่าบริการไม่ได้ถูกเปิดให้ใช้
#service ldap start เป็นวิธีเปิดบริการ ldap อีกแบบ
#/etc/init.d/ldap status เป็นวิธีตรวจสอบสถานะว่า running รึเปล่า
5. ทดสอบสั่ง start อีกแบบด้วย #/usr/sbin/slapd หรือ slapd -d 10
เมื่อตรวจ status ก็พบว่า ระบบเปิดบริการแล้ว (เรียกว่าเปิดบริการแบบ manual)
แต่ก็ต้องหาว่าสาเหตุคืออะไรต่อไป เพราะ ไม่สามารถ start ตามปกติได้
6. พบสาเหตุว่าเจ้าของแฟ้มในห้อง myname ไม่ใช่ ldap:ldap แต่เป็น root:root
จึงต้องเปลี่ยนเจ้าของ #chown ldap:ldap * ในห้อง /var/lib/ldap/myname
สรุปว่า ใช้งานได้ปกติหลังเปลี่ยนเจ้าของ
7. ใช้โปรแกรมจาก http://www.ldapadministrator.com/
ซึ่งเป็น ldap client admin เข้าไปจัดการข้อมูลได้ครับ

28 ก.ค.58 คุณตั้งแจ้งว่า verify stdid ไม่ผ่านอีกแล้ว หลังไฟดับเมื่อเช้า
หารือกับคุณตุ้ย ก็พบว่ามีปัญหาจริง ซึ่งก็ไม่รู้ว่าเกี่ยวกับไฟฟ้าดับรึเปล่า
ใช้วิธีข้างบนไม่ขลังเหมือนก่อน  ทั้งคุณเปรม และผมปลุกตามวิธีเดิม ๆ ก็ไม่ขึ้น
แล้วเวลาสั่ง start พบคำว่า
Finding last valid log LSN: file: 7 offset 8689191
Recovery starting from [7][8689099]
Recovery complete at Tue Jul 28 15:31:48 2015
Maximum transaction ID 80000007 Recovery checkpoint [7][8689191]

สรุปว่าลองลบ log
แล้วแฟ้ม ___db.001 ก็มากันปกติ จึงได้ใช้ chown จากนั้นก็ ok
แต่ก็ไม่แน่ใจ เพราะปัญหาหายไปแล้ว ถ้าเกิดอีกค่อยตามร่องรอยกันใหม่

http://www.thaiall.com/blog/admin/4282/
http://www.thaiall.com/blog/burin/3713/
http://www.thaiall.com/blog/burin/3698/
http://www.thaiall.com/blog/burin/3680/

fail to restart ldap
fail to restart ldap

สถิติของ histats.com ทำให้มั่นใจว่า web server ล่มจริง

webserver down
webserver down

18 พ.ค.54 วันนี้นั่งปรับปรุงเว็บไซต์ มีการ upload ตลอดเวลา มาใจหายวาบเกือบชั่วโมง เพราะ web server ล่มตอน 2 ทุ่มกว่า อาการ คือ เปิดเว็บไซต์ไม่ได้ ไม่พบโดเมนเนม ติดต่อผ่าน ftp ก็ไม่ตอบ หรือ ping ก็ไม่ตอบ มีโอกาสเกิดได้หลายกรณี .. แต่สรุปว่าล่มไปไม่ถึงชั่วโมง ก็พอรับได้ครับ สำหรับสถิติในวันก่อนหน้านี้จะไม่ลดฮวบแบบนี้ จึงสรุปได้ว่าระบบเครื่องบริการล่มจริง มิได้เกิดเฉพาะจากเครื่องของผม ซึ่งสถิตินี้ได้จากระบบบริการของ http://www.histats.com

ตัวตายตัวแทนกับปัญหาเน็ตล่ม

18 ธ.ค.52 วันนี้ระบบ DHCP Server ที่ทำหน้าที่แจกไอพีทำงานผิดปกติ ช่วงเช้ามีสายเข้ามาหน่วยงานไอทีมากกว่า 10 สาย ลองทดสอบดูก็พบว่ามีปัญหาจริง แต่ผู้ดูแลระบบมือหนึ่งติดภาระกิจ และอยู่นอกพื้นที่ ครั้งนี้โชคดีที่ อ.วิเชพ ใจบุญ ผู้เชี่ยวชาญเกี่ยวกับระบบเครือข่ายเข้ามาช่วยดู ทำให้พบหลายประเด็นที่นำไปสู่การแก้ไข ดังนี้ 1) วันนี้ระบบอินเทอร์เน็ตภายในที่ร้องขอบริการจากเครื่อง DHCP ไม่แสดงหน้า Login ทำให้ไม่มีใครในองค์กรใช้อินเทอร์เน็ตได้ 2) 2 วันที่ผ่านมามีการ upgrade  DHCP Server 3) 2 สัปดาห์ที่ผ่านมาระบบ Login ของ DHCP Server ตอบสนองช้าผิดปกติ จึงเป็นที่มาของข้อ 2 4) อ.วิเชพ พบว่าเมื่อยกเลิก User Authentication แล้วเข้าอินเทอร์เน็ตได้ปกติ 5) แต่เวลาต่อมาพบว่าเข้าอินเทอร์เน็ตได้เฉพาะเว็บไซต์ของมหาวิทยาลัย ออกไปเว็บไซ์ภายนอกไม่ได้
     6) พบว่ามีนโยบายกำหนด Load Balance ทำงานกับ ADSL และ Leased Line แต่ ADSL ล่ม ทำให้อินเทอร์เน็ตของผู้ใช้ทุกคนล่มด้วย ถ้าแก้ไขก็ทำได้ด้วยการ config ให้ล่มขาใดแต่ออกอีกขาได้เอง .. เจอกรณีนี้เพราะทั้งองค์กรมีเครื่อง อ.เชพ ออกเน็ตได้เครื่องเดียว เนื่องจากกำหนดนโยบายให้ออก Leased Line แต่ของทุกคนในมหาวิทยาลัยผ่าน Load Balance เมื่อ Load Balance ล้ม ทำให้เครื่องของ อ.เชพ เป็นเครื่องเดียวที่หลุดผ่านนโยบายข้อนี้ออกไปได้ และเป็นเหตุให้พบปัญหาที่การ config ที่เกิดขึ้นหลัง upgrade DHCP Server 7) ผลการตรวจ ADSL พบว่าไม่สามารถเชื่อมกับผู้ให้บริการ คือไฟ internet ที่ router ไม่ขึ้น จึงย้าย Net ทั้งหมดมาไว้กับ Leased Line เป็นวิธีแก้ปัญหาจากข้อ 6 8) แก้ปัญหา ADSL ล่มได้ แต่ Login ยังช้าเหมือนเดิม เป็นปัญหาพื้นฐานที่พึงเกิดขึ้นไม่นานมานี้
     9) อ.วิเชพ สงสัยว่าการย้ายข้อมูลผู้ใช้ เป็นแบบ import หรือ copy เพราะถ้า DHCP Server ต่างรุ่น การคัดลอกมาอาจมีปัญหา ต้องรอสอบถามจากผู้ดูแลระบบมือหนึ่งก่อน เพราะระบบสมาชิกองค์กรเป็นเรื่องใหญ่ ที่อาจเป็นต้นเหตุของหลายปัญหาได้
10) พบว่าการกำหนด Gateway 2 เบอร์ผิดจากที่ควรจะเป็น แต่แก้ไขให้เลือกเบอร์เดียวก็ไม่ทำให้ปัญหาหมดไป 11) มีข้อสงสัยเรื่องเว็บเพจ Login ที่มีการแก้ไขมาหลายสัปดาห์แล้ว และแก้กลับคืน แต่วันนี้พบเว็บเพจ Login รุ่นเดิมที่ใส่ภาพกิจกรรมนักศึกษาเข้าไป ซึ่งไม่น่าจะแสดงขึ้นมาได้อีก อาจเป็นปัญหาทาง Script ของระบบที่ incompatible กับ DHCP Server 12) มีการแก้ไขให้ใช้ได้ และผ่าน  User Authentication ประมาณ 13.00น. แล้วผลทดสอบก็ใช้งานได้ แต่ได้รับแจ้งจาก อ.ตา และ อ.บอย ว่า 17.00น. ยังมีปัญหาเข้า net ไม่ได้เกิดขึ้นอีก ถ้าเป็นจริงคงต้องยกเลิก User Authentication เหมือนที่ทำในข้อ 4 ไปก่อน เพื่อให้ใช้งานได้ และรอหารือกับผู้ดูแลระบบมือหนึ่งที่ติดภาระกิจ และอยู่นอกพื้นที่
??? เรื่องนี้ผู้ใช้ทั่วไปคงอ่านเข้าใจยาก .. ผมใช้เตือนความจำระหว่างทีมไอทีเป็นเป้าหมาย