นโยบายการจัดการความรู้ มหาวิทยาลัยสงขลานครินทร์ 1.ให้ใช้เครื่องมือการจัดการความรู้ผลักดัน คุณภาพคน และกระบวนทำงาน 2.ส่งเสริมการแลกเปลี่ยนประสบการณ์การทำงาน จากหน้างาน 3.ส่งเสริมให้มีเวทีเรียนรู้ร่วมกัน

นาย ฉัตรชัย จันทร์พริ้ม
Ico64
เครือข่าย
สมาชิก · ติดตาม: 4 · ผู้ติดตาม: 5

ความเคลื่อนไหวของฉัน

10 มีนาคม 2556
Ico48
Small_load-20130305
ภาระงานของ share วันจันทร์ที่ 4 มีค. 2556
โดย นาย ฉัตรชัย จันทร์พริ้ม
ดอกไม้: 0 · ความเห็น: 0 · อ่าน: 326
Ico48
Small_load-20130304
ภาระงานของ share วันอาทิตย์ที่ 3 มีค. 2556
โดย นาย ฉัตรชัย จันทร์พริ้ม
ดอกไม้: 0 · ความเห็น: 0 · อ่าน: 379
Ico48
Small_load-20130303
ภาระงานของ share วันเสาร์ที่ 2 มีค. 2556
โดย นาย ฉัตรชัย จันทร์พริ้ม
ดอกไม้: 0 · ความเห็น: 0 · อ่าน: 337
Ico48

ชอบ

Ico48
รวมบันทึกใหม่ในรอบ 7 วัน (2 - 8 มีนาคม 2556) ของ Share.psu
ใน เรื่องเล่าและเรื่องคุยจากห้องแล็บเคมีคลินิก
โดย โอ๋-อโณ
ต้องร้องอู้ฮู้..กับสถิติสัปดาห์นี้ของวงShareของเราเพราะมีบันทึกรวมแล้ว 128 บันทึกค่ะ อ่านกันสนุกไปเลย จากสมาชิกผู้เขียนทั้งหมดมี 55 ท่านค่ะ หวังว่าทุกๆท่านที่ได้ลงมือเขียนกันแล้วจะพยายามเขียนให้สม่ำเสมอต่อๆไปนะคะ เอามารวมให้กดตามลิงค์ไปอ่านกันตามเคยค่ะ ถ้าชอบใจก็อย่าลืมให้ดอกไม้คนเขียน และออกความ...
ดอกไม้: 13 · ความเห็น: 6 · อ่าน: 2722
18 กุมภาพันธ์ 2556
Ico48
ทดสอบ blog จาก สนง. อธิการบดี
ใน ฯลฯ
โดย นาย ฉัตรชัย จันทร์พริ้ม
ระหว่าง การประชุม ทดสอบ ก่อนที่ battery ของ notebook จะหมด
ดอกไม้: 4 · ความเห็น: 1 · อ่าน: 1155
15 กุมภาพันธ์ 2556
Ico48

ชอบ

Ico48
ปรับปรุงความปลอดภัยของโปรแกรมระบบวินโดส์ เดือนกุมภาพันธ์ พ.ศ. 2556 และปรับปรุงความปลอดภัยของโปรแกรม จาวา Java 7 Update 13
ใน ไอทีจิปาถะ
โดย สงกรานต์
สวัสดียามเย็นวันศุกร์ครับ ห้วงเวลาแห่งวันวาเลนไทน์ผ่านไปไม่นาน และแต่ก็นานสำหรับระบบความปลอดภัย เวลายังไม่ครบเดือนหลังจาก 2 บันทึกข้างล่าง วันที่ 4 และ 11 ก.พ. 2556 ก็มีการประกาศไฟล์ปรับปรุงความปลอดภัยของระบบใหม่(อีกแล้ว) ปรับปรุงความปลอดภัยของโปรแกรม จาวา และให้เลิกใช้ Internet Explorer 6-7-8 ...
ดอกไม้: 9 · ความเห็น: 0 · อ่าน: 2343
23 มกราคม 2556
Ico48

คุณเมตตาครับ

ใส่รูปแล้วครับ

ถ้าเกิด share down ไปเพราะผมทำอะไรพลาด

จะได้ตามล่าตัวได้ถูกต้องใช่ใหมครับ -_-"

จะพยายามระมัดระวังตัว ไม่ให้ถูกล่า ... เอ๊ย ไม่ใช่

ไม่ให้พลาด, ไม่ให้ down, ไม่ให้พัง, ไม่ให้ข้อมูลหายครับ! :)

22 มกราคม 2556
Ico48

คุณ Shangri-La ครับ, ขอบคุณครับ สำหรับคำแนะนำ ช่วง 2-3 คืนที่ผ่านมา เวลาของการ backup จะใช้เวลาประมาณ 3 ชม. 10 นาที ส่วนคืนที่นานที่สุด จะใช้เวลา 3 ชม. ครึ่ง (หลังจากย้ายเวลาของการ backup มาเป็นช่วงกลางคืน) คืนนี้ ผมจะลองเลื่อนไป backup เวลา 0100 ซึ่งเวลาโดยประมาณที่จะ backup เสร็จจะเป็นเวลา 0510-0530 จะทำให้พอมีเวลาประมาณ 30 นาทีสำรองก่อน 6 โมงเช้า ผมยังไม่อยากที่จะเลื่อนเวลาไปนานกว่านั้นครับ เพราะ ช่วง 6 โมงกว่าเป็นต้นไปจะเป็นช่วงเวลาที่ระบบ เริ่มงานจัดการภาระประจำวันอื่นๆ (daily cron task) ที่ไม่เกี่ยวข้องกับการให้บริการ share โดยตรง แต่จะมีภาระเกี่ยวกับการ อ่าน/เขียน ข้อมูลบน disk อยู่พอสมควร ซึ่งอาจจะทำให้ทั้งการ backup เอง และ การทำงานอื่นๆเองช้าลงไปด้วยครับ ส่วนเรื่องของการปรับแต่งอื่นๆ ที่อาจจะกระทบของการทำงานของ share โดยตรง คงต้องขอเวลาศึกษาระบบอีกสักพักครับ

Ico48

@Our Shangri-La ตามที่ผมได้อธิบายไปครับ มันเป็น load เนื่องจากการ backup ครับ

@สงกรานต์ ขอบคุณครับ สำหรับข้อมูลเพิ่มเติม

Ico48

แหะๆ ขอโทษด้วยครับ อ.ชาคริต จริงๆแล้วใน post ฉบับนี้ควรที่จะมีข้อมูลรายละเอียดมากกว่านี้หน่อยนึง

ยกตัวอย่างเช่น กราฟในรูป เวลาที่ขอบของแกน Y ไม่ใช่เวลา 00:00 ของวันนั้นๆ แต่จริงๆแล้วเป็นเวลา 23:00 ของวันที่แล้วครับ

ถ้าอาจารย์ จะเพ่งดูที่ตัวเลขที่ใต้กราฟหน่อยนึง ตัวเลขที่แสดงเวลา 00:00 และ 12:00 จะมี แท่งสีแดงเล็กๆบางๆ อยู่เหนือตัวเลข 0 ตัวแรกของ 00:00 และเหนือตัวเลข 1 ของ 12:00 เพราะฉะนั้น load ที่อาจารย์เห็นสูงอยู่ในกราฟและเข้าใจว่าอยู่ในช่วง 00:00-02:00 จริงๆแล้ว มันเริ่มที่ 23:00 ของวันที่แล้วครับ

ส่วนอีกข้อนึงก็คือ ที่มาของกราฟอันนี้ เกิดจากวันจันทร์ของสัปดาห์ที่แล้วซึ่ง share มีอาการช้ามาก จนสังเกตุเห็นได้จากผู้ใช้หลายๆท่าน และระบบซึ่งในในการ monitor มันส่งคำเตือนมาว่า share ไม่ตอบสนองในช่วงเวลาที่กำหนด คุณสงกรานต์ส่ง message มาทาง facebook ผมก็เลยต้องหาวิธีการบันทึก ภาระงานของ share ที่เกิดขึ้นในช่วงวันว่ามันมีภาระเป็นเท่าไหร่บ้าง และภาระเกิดขึ้นจากส่วนใหนบ้าง และจะลดภาระเพื่อแก้ปัญหาการตอบสนองช้า ได้อย่างไรบ้าง ... ซึ่ง ... ดูแล้วก็ยังต้องใช้เวลากันอีกพอสมควรครับ

แต่ในขั้นแรก หลังจาก เก็บข้อมูลในช่วงวันจันทร์และอังคารได้แล้ว ก็เจอว่า share จะมีภาระหนักในช่วงเวลากลางวัน และ เบาในช่วงเวลากลางคืน ... อันที่จริงแล้วไม่ต้องมาเก็บข้อมูลก็พอที่จะเดาเรื่องนี้กันได้ ใช่ใหมครับ แต่จากข้อมูลที่เก็บทำให้ได้ตัวเลขที่ชัดเจนขึ้นว่า ภาระงานมันมากขนาดใหน และ นอกจากนี้ ในการตรวจสอบ ภาระงานอื่นๆบนระบบ นอกเหนือไปจากการให้บริการของ share เอง ก็ยังพบว่า มีเรื่องของการ backup ข้อมูลระบบ share ไปเก็บเอาไว้ ซึ่งเริ่มต้นทำในช่วง เวลาประมาณ 06:30 และเสร็จในเวลาประมาณ 13:30 (ของวันจันทร์, อังคาร สัปดาห์ที่แล้ว) ซึ่งก็เป็นส่วนหนึ่งของการเพิ่มภาระของ share ในช่วงเวลากลางวัน ทั้งที่งานในส่วนนี้ ไม่จำเป็นที่จะต้องทำในช่วงนั้น ในช่วงกลางคืนของวันอังคาร ผมก็เลยปรับเปลี่ยนให้เรื่องของการ backup เริ่มเร็วขึ้น คือเริ่มที่เวลา 23:00 ของคืนนั้น แทนที่จะเริ่ม 06:30 ของวันถัดไป

ซึ่งผลที่ได้ก็คือ ระยะเวลาของการ backup ลดลงจาก เดิมใช้เวลาประมาณ 7 ชม. เหลือเวลาประมาณ 4 ชม. ครึ่ง ภาระงานของ share ในช่วงเวลากลางวัน ลดลงจากการแกว่งในระดับ 10-11 ของวันอังคารช่วงเช้า ซึ่งยังมีการ backup ข้อมูลทำขนานกันไป ลงมาเหลือ 8-9 ของวันพุธเช้า ซึ่งใกล้เคียงกับ วันอังคารช่วงบ่าย ซึ่งการ backup ข้อมูลเสร็จแล้ว

โดยสรุป สิ่งที่อธิบายมาข้างต้น ผมควรจะเขียนอธิบายไว้ในบันทึก (แต่ไม่ได้ทำ :~( ...) ก็เลยต้องเอามาตอบอาจารย์ในที่นี้ เพื่อที่จะอธิบายว่า ในช่วงเวลา 00:00-02:00 ที่อาจารย์เห็นว่ายังมีการใช้งาน share กันอยู่ด้วย จริงๆแล้ว เป็นภาระงานที่เกิดขึ้นในช่วง 23:00-03:30 ซึ่งเป็นการ backup ข้อมูลครับ ส่วนการใช้งานจะมีอยู่บ้างใหม ... ก็อาจจะมีครับ แต่จะมีเท่าไหร่ และต่างจากในช่วงเวลากลางวันมากขนาดใหน อันนี้ ในตอนนี้ ผมยังไม่มีความสามารถที่จะดึงข้อมูลจากในระบบ share เองมาตอบคำถามนี้ได้ครับ ... คือ ข้อมูลมันมีครับ ... แต่ความสามารถของผมตอนนี้ยังไม่มี คงต้องขอเวลาอีกสักพักในการทำความเข้าใจระบบที่มีอยู่ เพื่อที่จะทำงาน ที่เคยรับปากใครหลายคนไว้เมื่อ 2-3 เดือนที่แล้ว แต่แทบที่จะไม่ได้ทำอะไรเลย (... ผมผิดไปแล้วคร้าบ, ผมผิดไปแล้ว, จะพยายามไม่ทำตัวเหลวไหลอีกแล้วคร้าบ ...) สำหรับการดูแลระบบ share ให้สามารถใช้งานต่อไปได้ครับ

Ico48
ภาระงานของ Share ในช่วง 1 สัปดาห์ที่ผ่านมา
ใน ฯลฯ
โดย นาย ฉัตรชัย จันทร์พริ้ม
วันอังคารที่ 15 มค. 2556 วันพุธที่ 16 มค. 2556 วันพฤหัสบดีที่ 17 มค. 2556 วันศุกร์ที่ 18 มค. 2556 วันเสาร์ที่ 19 มค. 2556 วันอาทิตย์ที่ 20 มค. 2556 วันจันทร์ที่ 21 มค. 2556 กราฟเส้นสีแดงจะเป็นค่า load ที่วัดทุกๆนาที กราฟเส้นสีเขียวจะเป็นค่า load เฉลี่ยในช่วง 5 นาที และกราฟเ...
ดอกไม้: 9 · ความเห็น: 12 · อ่าน: 1784
Ico48
Small_load-20130121
load-20130121.png
โดย นาย ฉัตรชัย จันทร์พริ้ม
ดอกไม้: 0 · ความเห็น: 0 · อ่าน: 372
Ico48
Small_load-20130120
load-20130120.png
โดย นาย ฉัตรชัย จันทร์พริ้ม
ดอกไม้: 0 · ความเห็น: 0 · อ่าน: 400
Ico48
Small_load-20130119
load-20130119.png
โดย นาย ฉัตรชัย จันทร์พริ้ม
ดอกไม้: 0 · ความเห็น: 0 · อ่าน: 417
Ico48
Small_load-20130118
load-20130118.png
โดย นาย ฉัตรชัย จันทร์พริ้ม
ดอกไม้: 0 · ความเห็น: 0 · อ่าน: 441
Ico48
Small_load-20130117
load-20130117.png
โดย นาย ฉัตรชัย จันทร์พริ้ม
ดอกไม้: 0 · ความเห็น: 0 · อ่าน: 419
Ico48
Small_load-20130116
load-20130116.png
โดย นาย ฉัตรชัย จันทร์พริ้ม
ดอกไม้: 0 · ความเห็น: 0 · อ่าน: 480
Ico48
Small_load-20130115
load-20130115.png
โดย นาย ฉัตรชัย จันทร์พริ้ม
ดอกไม้: 0 · ความเห็น: 0 · อ่าน: 581
18 กันยายน 2555
Ico48

ผมใช้ package ที่ชื่อว่า logrotate ครับ

ตัวนี้สามารถเลือกที่จะ rotate logfile ใดๆตามความเหมาะสมได้

โดย default แล้ว บน debian (ซึ่งน่าจะรวม ubuntu ด้วย) มันจะ rotate ไฟล์

log และ error ของ apache2 ทุกๆสัปดาห์ และเก็บ log ไว้ 4 สัปดาห์

ผมปรับแก้ให้เก็บได้นาน 1 ปี โดยการเปลี่ยนตัวเลขใน config ไฟล์แค่ตัวเดียว

ผมคิดว่าใช้ logrotate จะดีกว่าครับ สามารถใช้จัดการกับ log ไฟล์ได้อย่างหลากหลาย

ไม่จำกัดเฉพาะ apache log และควบคุมทั้งหมดผ่านจุดควบคุมเพียงจุดเดียวกันครับ

15 ธันวาคม 2554
Ico48

ประเด็นที่ 1 ... อันนี้ผมไม่แน่ใจเพราะถ้าใช้ script psuautosigned ผมยังได้รับ cookie อยู่ ถึงแม้ว่าจะมีปัญหากับการ redirect ... แต่ไม่ว่าจะมี cookie หรือไม่ตัว psuautosiged ก็จะวน loop พยายาม login ใหม่ให้ครับ

ประเด็นที่ 2 เรื่องของ news feed ใช้ตัวนี้ได้ครับสำหรับการอ่านจาก command line

http://fivedots.coe.psu.ac.th/~cj/scripts/getccnewsfeed.txt

ฉัตรชัย