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

ภาระงานของ Share ในช่วง 1 สัปดาห์ที่ผ่านมา ...

บางที ... ผมก็สงสัยว่าตัวเองมีอาการทางจิตประเภทย้ำคิดย้ำทำ ... หรือเปล่า

บางที ... ผมก็สงสัยว่าตัวเองมีอาการทางจิตประเภทย้ำคิดย้ำทำ ... หรือเปล่า

คือแบบว่า เมื่อไหร่ที่เปิด บันทึกของ share ขึ้นเมื่อไหร่ ทั้งๆที่ค่อนข้างจะมั่นใจตัวเอง (แบบ ... เข้าข้างตัวเองน่ะครับ) ว่ามีเรื่องที่จะเขียนอยู่พอสมควร แต่พอจะเขียนทีไร มันก็จะวกไปหาเรื่องภาระของ share อยู่ซะทุกทีสิน่า ... ไม่มีเรื่องอื่นเอามาเขียนแล้วหรือไง?

ก็คงต้องปล่อยให้เป็นข้อสงสัยต่อไปครับ ยังไงผมก็จะพยายามหลีกหนี ไม่เข้าใกล้แผนกจิตเวช ของโรงพยาบาลใหนๆให้เขาจับตัวผมไปตรวจพิสูจน์เป็นแน่ๆ กลัวเขาจับได้ว่าผมแอบหนีมา ... เฮ่ย! ไม่ใช่!

กลับมาที่เรื่องของ load ของ share อีกรอบก็แล้วกันครับ ... หลังจากผม upload graph ของภาระงานไปสองรอบ ในสองบันทึกก่อนหน้าโน้น นี่ กับ นี่ โดยในแต่ละบันทึกก็จะมีรูป 7-8 รูป ในแต่ละบันทึก ถ้าจะทำแบบเดิมอีกรอบ ... หรืออีกหลายรอบ (ถ้าตั้งใจจะเอาเรื่องนี้มาหากินไปเรือยๆ จนกว่าคนอ่านเขาจะเบื่อไปเอง แล้วเลิกเข้ามาอ่าน/เมนท์) ก็ชักขี้เกียจขึ้นเรื่อยๆ ... ซึ่งเป็นอาการปกติของคนที่ทำหน้า admin มานานๆครับ

ซึ่งในแวดวง admin ผู้สูงด้วยวัยวุฒิและคุณวุฒิ ก็จะถือว่านั่นเป็นลักษณะที่ดี ลักษณะหนึ่งของผู้ที่ทำงานเป็น admin (ผู้ดูแลระบบ)

เอ๊ะ! ยังไงกัน สำหรับ admin ความขี้เกียจนี่เป็นเรื่องดีงั้นรึ?

แหะๆ ก็ยังไม่ใช่ซะทั้งหมดซะทีเดียวครับ คือลักษณะ ซึ่งจะเรียกว่า 'คุณ'ลักษณะ หรือ 'โทษ'ลักษณะ ก็ไม่ถูกต้องซะทีเดียวนัก ... เอาเป็นว่ามันเป็นแค่ "ลักษณะ" หนึ่งก็แล้วกันครับ

สำหรับ admin แล้ว การจะทำงานใดๆที่ซ้ำๆแบบเดิมไปเรื่อยๆนั้น ไม่ได้ถือว่าเป็นเรื่องที่ดีนัก admin ที่ดีควรที่จะมองหารูปแบบที่ทำซ้ำๆกันเหล่านั้น แยกแยะกระบวนการออกมาว่า มีขั้นตอนอะไรที่ทำซ้ำกันบ้าง และพัฒนาเครื่องมือ หรือกระบวนการใหม่ ซึ่งจะลดกระบวนการที่ซ้ำซ้อนเหล่านั้นให้เหลือน้อยที่สุด และใช้เครื่องมือเหล่านั้นในการทำงานแทน เพื่อที่จะได้มีเวลาว่างไปเล่น... เอ๊ย! ไป "ทำงาน" อะไรอย่างอื่นที่มีคุณค่ามากกว่าแทน

เพราะฉะนั้น ในแง่มุมของ admin แล้ว แรงจูงใจหรือแรงผลักดันอันแรก ซึ่งจะทำให้ "มองเห็น" ว่ากระบวนการนั้น เป็นกระบวนการซ้ำซ้อน, น่าเบื่อ จึงเป็นความ "ขี้เกียจ" หลังจากนั้น ถึงจะใช้ "ความพยายาม" ในการ "มองหา" เครื่องมือ/วิธีการ ที่จะใช้ในการลดความซ้ำซ้อนอันนั้น

admin ที่ขาดความ "ขี้เกียจ" ในขั้นแรก ก็จะมีความขยันที่จะทำงานเดิมๆซ้ำๆซ้อนๆ ต่อไปได้เรื่อยๆ ซึ่งก็จะทำให้งานนั้นๆ สำเร็จลงได้ แต่ขาดการ "พัฒนา" อย่างที่ควรที่จะเป็น

admin ที่มีความ "ขี้เกียจ" ที่อาจจะมองเห็นความซ้ำซ้อนของการทำงาน แต่ ขาดความ "พยายาม" ที่จะหาวิธีการในการลดความซ้ำซ้อน ส่วนใหญ่ก็คงเปลี่ยนอาชีพไปทำอย่างอื่นแทนครับ เพราะคงจะไม่สามารถทนกับงานแบบเดิมๆอยู่ได้ตลอดไป

ผมเป็น admin ที่มีความ'ขี้เกียจ'เป็นลักษณะปกติ แต่ก็ยังโชคดีที่ยังพอมีความ'พยายาม'อยู่บ้าง ก็เลยพอจะเอาตัวรอดมาได้อยู่หน่อยนึง (แบบ... ทำงานในฐานะ admin มานาน ไม่ค่อยมีใครชม ขอชมตัวเองบ้างก็แล้วกัน หึ, หึ, หึ)

แต่ยังไงก็คงเป็น admin ฝีมือระดับพื้นๆเท่านั้นแหละครับ เพราะยังต้องใช้เวลาถึงรอบที่ 3 ถึงจะ "มองเห็น" และ "มองหา" เครื่องมือมาทำงานแทนงานที่ต้องทำซ้ำๆ ... admin ฝีมือดีจะทำแค่รอบเดียวเพื่อที่จะเรียนรู้กระบวนการ ว่าจะมีขั้นตอนอะไรอย่างไรบ้าง เพื่อที่จะสร้างเครื่องมือ และใช้เครื่องมือนั้นในการทำงาน ไม่จำเป็นจะต้องทำในรอบที่สอง และรอบถัดๆไป แต่สำหรับ admin ฝีมือ "ขั้นเทพ" นั้น จะใช้เวลาสำหรับการ "ลับขวาน" ตัดไม้ ตั้งแต่รอบแรกแล้ว โดยไม่ต้องทดลองตัดไม้ด้วยขวานที่ไม่คม เพื่อที่จะรู้ว่าจะต้องใช้เวลาเท่าไหร่ถึงจะโค่นต้นไม้โดยขวานที่ไม่คมได้

... และก่อนที่จะออกทะเลต่อ ผมก็ขอเสนอผลงานที่ผมจะแสนภูมิใจ
... น่าๆ ไม่มีอะไรน่าตื่นเต้นเท่าไหร่ แต่ผมก็ภูมิใจในงานของผมล่ะน่า ...



URL สำหรับจะเข้าไปดู load ย้อนหลังไป 1 สัปดาห์ จะสามารถเข้าไปดูได้ที่

http://fivedots.coe.psu.ac.th/~cj/tmp/share/weekly ครับ

โอเค ... เอาล่ะ นอกเหนือจาก เอา load ของ share มาให้ดูแล้ว ผมทำอะไร share บ้างหรือเปล่านี่ ... ฮาๆ ... นั่นสิ หน้าที่ของผู้ดูแลระบบ ใช่ว่าจะนั่งพลอตกราฟ แล้วเอารูปมาให้ดูอย่างเดียวซะเมื่อไหร่ล่ะ

ในเรื่องที่ผม "ควร" ที่จะทำจริงๆนั้น ก็คือจัดเตรียมระบบให้ "ใช้งานได้" ...
เอ่อ ... ก็มันใช้งานได้อยู่นี่!

ครับ ในช่วงเวลาอันใกล้นี้ก็คงไม่มีปัญหาอะไรในการใช้งาน ... ถ้าจะมีปัญหาให้มันใช้งานไม่ได้ ปัญหานั้นก็อาจจะมาจากผมเข้าไปยุ่งกับมันเกินกว่าที่จำเป็น แล้วทำให้ระบบมันใช้งานไม่ได้น่ะแหละ

งั้น ... ทิ้งให้ระบบมัน "ใช้งานได้" อยู่อย่างนี้ ไม่ดีกว่าหรือ ถ้าจะมี admin แล้ว "อาจจะ" ทำให้ระบบมีปัญหา "ใช้งานไม่ได้" ขึ้นมา

ก็ ... อาจจะเป็นอย่างนั้นครับ แต่ว่า เช่นเดียวกับ "ระบบ" อื่นๆ ที่มีความซับซ้อนและมีการใช้งานอยู่อย่างต่อเนื่องโดยทั่วไป ระบบ ไม่สามารถที่จะทำงานอยู่ตลอดไปได้ โดยไม่มีการดูแล

ภาควิชาวิศวกรรมคอมพิวเตอร์ มีเครื่องคอมพิวเตอร์ซึ่งพอจะจัดได้ว่าอยู่ในระดับของ Server Grade คือออกแบบมา ถึงแม้มองดูจากภายนอกแล้วหน้าตาไม่ต่างเครื่อง Desktop โดยทั่วไป แต่อุปกรณ์และการออกแบบ ทำมาแบบเดียวกับเครื่องเซิร์ฟเวอร์ เครื่องคอมพิวเตอร์เครื่องนี้ อายุกว่า 14 ปีแล้ว แต่ยังใช้งานได้จนถึงปัจจุบัน แต่ก็ถือได้ว่าเครื่องนี้เป็นกรณีพิเศษ ลักษณะการใช้งานเป็นของมันเป็นแบบ router/gateway สำหรับเครือข่ายเฉพาะทาง ซึ่งในแง่ของภาระงานไม่ได้มีการเปลี่ยนแปลงมาก ความสามารถของเครื่องที่ผลิตมาเมื่อ 10 กว่าปีที่แล้วก็ยังสามารถรับภาระงานนั้นได้อย่างไม่มีปัญหา อุปกรณ์ทั้งหลาย ยังสามารถใช้งานได้เป็นปกติ ... แต่ถ้าจะเทียบกับเครื่องอื่นๆซึ่งภาควิชาฯได้รับมาในช่วงเวลาเดียวกัน ตอนนี้ก็เลิกใช้ไปหมดแล้ว ซึ่งมาจากทั้งกรณีที่ความสามารถของมันที่ไม่สามารถให้บริการตามความต้องการที่มีอยู่ในขณะนั้นๆได้ และอุปกรณ์ที่ค่อยๆเสียหายไปตามกาลเวลา และการเปลี่ยนอุปกรณ์เพื่อจะให้เครื่องใช้งานต่อไปได้ จะเริ่มไม่คุ้มค่าเนื่องจากสามารถชื้อเครื่องคอมพิวเตอร์ใหม่ซึ่งมีประสิทธิภาพสูงกว่ามาแทนที่ได้ในจำนวนเงินเดียวกันหรืออาจจะน้อยกว่า

ในกรณีของ share ก็เช่นเดียวกัน เมื่อถึงจุดหนึ่ง เพื่อให้ระบบ share สามารถทำงานต่อไปได้ เราก็ต้องการอุปกรณ์ใหม่มาทดแทน ในแต่ละส่วนที่จะเสื่อมไปตามกาลเวลา 'เวลา' ที่ว่านั่นอาจจะยังไม่ใช่ตอนนี้ อาจจะยังใช้งานต่อไปได้อีก 1-2 ปี หรือนานกว่านั้น แต่ในฐานะของ admin ที่ทำงานในลักษณะนี้มานานระดับหนึ่ง ผมไม่ได้คาดหวังอะไรมากขนาดนั้น ประสบการณ์ของผมเตือนว่า ช่วงที่ผมรู้สึกว่างานสบายๆไม่มีอะไรกดดันมากที่สุด ช่วงนั้นอาจจะเป็นช่วงที่อันตรายมากที่สุด ... และช่วงนี้เป็นช่วงหลังสอบเสร็จ ส่งเกรดเสร็จ และรู้สึกเป็นช่วงพักผ่อนมากที่สุดด้วย (ฮา)

ผมควรที่จะทำอะไรกับ share? ในฐานะของ admin ที่รับปากว่าจะมาดูแล เพื่อที่จะส่งต่องานให้กับผู้ที่จะมารับในช่วงต่อไปได้ คำตอบสำหรับตัวผมเองก็คือ เตรียมระบบที่จะให้สามารถโอนย้ายไปยังเครื่องคอมพิวเตอร์เครื่องอื่นได้ เมื่อถึงเวลาจำเป็น

ผมไม่ควรที่จะมายุ่งกับเรื่องของ load อะไรในตอนนี้ เพราะถึงแม้ load ของเครื่องปัจจุบัน มันสูงไปบ้างในบางช่วง แต่ถ้ามันไม่ทำถึงกับให้ระบบใช้งานไม่ได้ ยังมีคนเขียนบันทึกใหม่ มีคนอ่าน มีการ comment กันอยู่กันอย่างเป็นปกติ ... ก็ถือว่ามันยังใช้งานได้อยู่ ... จะไปยุ่งอะไรกับมันเล่า!

แหม่ ... จริงๆแล้วผมก็ทำอย่างนั้นอยู่แหละครับ แต่ แบบว่า ... เอาเข้าจริงระบบ share ที่มีอยู่ปัจจุบัน มีส่วนที่ไม่ได้ทำตามสิ่งที่เรียกว่า convention ของ เซิร์ฟเวอร์ ที่ให้บริการบนเครื่องคอมพิวเตอร์ซึ่งใช้ระบบปฏิบัติการแบบ Linux ในตระกูลของ Debian/Ubuntu อยู่ในระดับพอสมควร ยกตัวอย่างเช่น ตำแหน่งของการเก็บ code ของตัวให้บริการ share, การจัดเก็บในส่วนของ ข้อมูล และ log ต่างๆ การ startup ตัว Server ซึ่งจะให้บริการ ซึ่งผมจะต้องทำความเข้าใจในส่วนต่างๆ เหล่านี้ก่อน ถึงจะสามารถย้ายระบบ ขึ้นไปทำงานบนระบบอื่นและสามารถทำงานอย่างถูกต้องได้

สาเหตุอันนึงก็น่าจะเป็นเพราะว่า ระบบ knowledgEvolution เดิมอาจจะพัฒนาบน platform FreeBSD และรวมทั้งการใช้เครื่องมือของ Ruby ซึ่งผมไม่คุ้นเคย ซึ่ง ...

จะพูดไปทำไมมี เอาเป็นว่า ผมยังไม่มีความรู้ความเข้าใจในระบบ มากเพียงพอที่จะทำหน้าที่เป็น admin ที่ดีได้ เท่านั้นเองแหละ (ฮา) นั่นคือสาเหตุที่แท้จริง ... หน้าที่ของ admin ก็คือหลังจากรับหน้าที่มาแล้ว ก็ต้องศึกษาระบบ ให้เข้าใจก่อน เพื่อที่จะสามารถ "จัดการ" กับระบบให้ได้แค่นั้นเอง ไม่มีอะไรอื่นให้จะต้องยกเอามาเป็นข้ออ้างใดๆ -_-"

ครับ ... ถ้าจะให้คำตอบว่า กำลังทำอะไรอยู่ ตอนนี้ก็คงตอบได้แค่ว่า "กำลังศึกษา" ระบบอยู่ครับ

แหะๆ ผมก็ไม่ควรจะไปยุ่งกับเรื่อง load เรื่องอะไร ...

แต่ระหว่างที่กำลังศึกษาอยู่นั้น มันก็เกิดความรู้สึก น่าจะแบบเดียวกับ นักศึกษาทั่วไป ก็คือ ไม่รู้ว่าเมื่อไหร่ถึงจะมีความก้าวหน้าที่เป็นชิ้นเป็นอัน เพราะองค์ความรู้ ที่มีอยู่ในตอนนี้ ยังไม่ถึงระดับ "เข้าใจ" มากพอที่จะทำอะไรกับระบบ โดยที่ "มั่นใจ" ว่าจะไม่ก่อให้เกิด "ปัญหา" กับระบบแทน

ดังนั้น ระหว่างที่กำลังศึกษาไป พอเห็นอะไรบางอย่าง ที่ไม่ใช่ประเด็นหลัก ของงานที่ "ควรทำ"/"ต้องทำ" แต่เป็นประเด็นปลีกย่อย ที่มีความสำคัญในระดับรองๆ ลงมา (รองลงมามากๆ) แต่ก็พอที่จะทำอะไรได้ ก็เลือกที่จะ "ทำ" ในเรื่องนั้นๆ ไปก่อน เพราะยังทำให้รู้สึกว่า "ได้ทำ" อะไรบ้าง นอกจาก "อ่าน" อย่างเดียว (ฮา)

... และ ผมก็ไปยุ่งกับ load ของระบบอีกน่ะแหละ ... เพราะนั่นดูเหมือนจะเป็นเรื่องที่เข้าใจง่าย (เฉพาะระดับหนึ่ง)

ในครั้งแรกที่ผม ต้องทำอะไรกับระบบของ share ทั้งที่ตอนนั้นก็ยัง ไม่ได้เข้าใจองค์ประกอบทั้งหมดสักเท่าไหร่ ส่วนหนึ่งก็เพราะ การแจ้งจากคุณสงกรานต์ว่า ระบบ is2monitor เตือนมาว่า share ไม่ตอบสนองกับตัว monitor จากภายนอก และ เมื่อมาตรวจสอบ load ของระบบก็พบว่า ในช่วงนั้นมี load สูงมากถึงระดับ 10-12 ในช่วงเวลากลางวัน เมื่อเทียบกับกลางคืนซึ่ง load อยู่ในระดับ ไม่เกิน 2

คำถามแรกก็คือว่าเครื่อง share ให้บริการอะไรบ้าง นอกเหนือจากการให้บริการระบบ share.psu.ac.th และ มีงานอะไรบ้างที่เกิดขึ้นในช่วงที่มี load สูงระดับนั้น

คำตอบนึงที่อาจจะเห็นได้ชัด (สำหรับ admin) ก็คือการจัดการระบบทั่วไปๆ ... สมมติ ถ้าเทียบระบบ share.psu.ac.th เป็นร้านอาหาร การให้บริการหลัก ก็คือปรุงอาหารให้กับลูกค้าที่มาทานอาหาร เครื่อง 'share' ก็เทียบได้กับ ตัวร้านอาหาร ที่ต้องมีการปัดกวาดดูแลและซ่อมแซมทุกวัน ลูกค้าเข้ามาใช้บริการในช่วงเวลาตั้งแต่ 8 โมงเช้าจนถึง 5 โมงเย็น และ การปัดกวาดดูแล เริ่มตั้งแต่ 6 โมงเช้า โดยทั่วไป การปัดกวาดดูแลควรจะเสร็จภายในเวลาไม่นาน ปรากฏว่า เอาเข้าจริง งานปัดกวาดนั้นกลับมีงานหนักซ่อนอยู่ ซึ่งทำให้งานนั้นแทนที่ควรจะเสร็จภายในไม่เกิน 10-15 นาที กลับยาวนานหลาย ชม. ตั้งแต่ 6 โมงเช้าถึงบ่ายโมง พนักงานนอกเหนือจะต้อง หุงหาอาหารและต้นระบลูกค้าแล้ว ก็ยังต้องมารับภาระปัดกวาดดูแลและซ่อมแซมอันนี้ด้วย ทำให้ให้บริการลูกค้าไม่ทัน

การจัดการแรกที่ผมเริ่ม 'จัดการ' สำหรับระบบ share ก็คือ 'ย้าย' งานของการ 'ซ่อมแซม' นั้นให้ไปเริ่มช่วงกลางคืนแทน ทำให้ภาระงานในช่วงกลางวันมีเหลือเฉพาะเรื่องของการให้บริการปกติของ share ซึ่งก็ทำให้ load ในช่วงกลางวันของระบบลดลง จากเดิมเคยสูงถึง 12 ในบางช่วง มาเหลือต่ำกว่า 8 ในช่วง peak

แต่จะว่าไป load นั้นไม่ได้หายไปใหน ผมแค่ 'ย้าย' มันออกไปช่วงอื่นแทน แค่นั้นเอง

ในกราฟของวันอังคารที่ 12 มีนาคม 2556 และวันอื่นๆ ก่อนหน้านั้น จะเห็น load ที่เริ่มสูงขึ้นเมื่อเวลา 01:00 ไปจนถึงเวลาประมาณ 04:30 ของทุกวัน โดย load จะขึ้นสูงอยู่ในช่วง 2-3 หรืออาจจะ peak ขึ้นสูงกว่านั้นในบางช่วง แต่ภาระงานเกือบทั้งหมดที่เกิดขึ้นในช่วงนี้จะเป็นเรื่องของการ backup ข้อมูลไฟล์ image ของภาพต่างๆให้เป็น backup ไฟล์ โดยจะบีบอัดให้อยู๋ในฟอร์แมทที่ชื่อ 7z

จำนวนไฟล์ทั้งหมด ที่ถูก compress และเก็บรวมกันไว้ โดยจะเก็บย้อนหลังไว้ 14 วัน (การ backup จะ backup วันละครั้ง)

งานที่ผมทำครั้งแรก เป็นเพียงปรับเปลี่ยนช่วงเวลาของการเริ่มงาน จากเดิมทีเป็น 6 โมงเช้าให้เป็นช่วงหลัง 5 ทุ่มในครั้งแรก และเปลี่ยนเป็นช่วง 01:00 ของวันใหม่ ตามคำแนะนำของคุณ Our Shangri-La

และหลังจากทิ้งเอาไว้ในสภาพนั้นไปเดือนกว่าๆ ก็มีเวลากลับมาดูอีกครั้ง ผมพบว่า การจัดเก็บโดยใช้ฟอร์แมท 7z นั้น อาจจะเป็นเรื่อง "เกิน" ความจำเป็น เพราะ format นี้จะทำให้มีการลดขนาดไฟล์ลงได้ดีกว่า format อื่นๆ เช่น zip หรือ gz อยู่พอสมควร แต่ในขณะเดียวกัน มันก็จะกินพลังานของ CPU ของเครื่องมากเช่นเดียวกัน นอกจากนี้ไฟล์ที่จัดเก็บเหล่านั้น เกือบทั้งหมดจะเป็นไฟล์ภาพ jpg หรือ gif ซึ่งโดยตัวมันเองนั้นจะเป้นไฟล์ที่มีการบีบอัดอยู่ก่อนแล้ว การที่จะบีบอัดซ้ำอีกครั้งจะทำให้ลดขนาดลงได้ "แต่" ไม่มาก นอกจากนี้ ถึงแม้ว่าไฟล์จะมีจำนวนมาก เนื้อที่โดยรวมของการเก็บจะมาก แต่ปัจจุบันเครื่อง share เอง ไม่ได้มีปัญหาเรื่องของเนื้อที่ที่ใช้ในการเก็บไฟล์ สิ่งที่มีปัญหาก็คือเรื่องของ กำลังของ CPU ที่ใช้ในการให้บริการต่างหาก

ช่วงเช้าของวันอาทิตย์ 10 มีค. 2556 ซึ่งโดยทั่วไปแล้วจะไม่มีคนใช้งาน ผมเลยลองสั่ง backup ข้อมูลโดยเปลี่ยนจาก 7z เป็น tar และบีบอัดโดยใช้ฟอร์แมท bz2 พบว่าสามารถลดเวลาจากประมาณ 4 ชม.ครึ่งเหลือเพียง 1 ชม.ครึ่ง โดยที่มีขนาดของไฟล์ที่ backup เพิ่มขึ้นหน่อยนึง จากเดิมจะมีขนาดประมาณ 18GB พอเปลี่ยนวิธีการเป็น bz2 ก็จะได้ขนาดเป็น 19GB

แต่ตรวจสอบจากเนื้อที่ไฟล์ที่ใช้งานแล้วมีขนาดประมาณ 22GB ซึ่งไม่ได้จ่างกันมาก ดังนั้นวันที่ 13 มีค. ผมก็เลยปรับเปลี่ยนวิธีการ backup จากเดิม 7z เป็น tar โดยไม่มีการบีบอัดเพื่อให้เสร็จเร็วที่สุด

ผลที่ได้ก็อย่างที่เห็นในภาพที่เปรียบเทียบกันระหว่างวันที่ 12 มีค. และ 13 มีค. ครับ ระยะเวลาของการ backup ลดลงจากเดิม 4 ชม.ครึ่ง เหลือเพียง ประมาณครึ่งชม. โดยในแต่ละครั้งของการ backup จะใช้เนื้อที่เพิ่มจากเดิม ซึ่ง backup ได้ครั้งละ 18GB เพิ่มเป็น 22GB

ขนาดของ backup file ล่าสุดจะมีขนาดตามที่เห็นครับ

ชื่อไฟล์ที่มีตัวเลขตามหลัง คือไฟล์ของวันก่อนหน้านั้นที่มีการ backup เอาไว้ซึ่งจะค่อยๆหมุนทยอยทับของเดิมไปเรื่อยๆ

... เอาล่ะครับ ผมคิดว่าผมยังสามารถ ปรับปรุงเกี่ยวกับเนื้อที่ในการจัดเก็บและลดเวลาในการ backup ได้อีกหน่อย ซึ่งจะทำให้ load ของระบบลดลง และน่าจะทำให้ backup ได้บ่อยขึ้นแทนที่จะเป็นวันละครั้งก็ ...

เอ่อ .... นี่ไม่ใช่งานที่ผมควรจะมายุ่งใช่ใหม -_-"

นั่นแหละครับ คือ พอมันมีงานที่ทำได้ง่ายกว่า ผมก็จะสนใจกับงานที่ง่ายกว่าซะทุกทีสิน่า ทั้งที่มันไม่ได้เป็นปัญหาอะไรในตอนนี้

ผมควรจะกลับไป ทำ "งาน" ที่แท้จริงของผมใช่ใหม

เฮ้อ ... งั้นบันทึกฉบับนี้ก็คงจะพอแค่นี้ก่อนครับ ถ้าทุกอย่างเป็นไปได้ด้วยดี "งาน" หลักที่ผมควรจะทำ ก็อาจจะมีความก้าวหน้าบ้างภายในสัปดาห์นี้ครับ แล้วจะเอามารายงานให้ทราบอีกทีครับ ... :)

หมวดหมู่บันทึก: เรื่องทั่วไป
สัญญาอนุญาต: ซีซี: แสดงที่มา-ไม่ใช้เพื่อการค้า-อนุญาตแบบเดียวกัน Cc-by-nc-sa
สร้าง: 19 มีนาคม 2556 17:48 แก้ไข: 19 มีนาคม 2556 17:48 [ แจ้งไม่เหมาะสม ]
ดอกไม้
สมาชิกที่ให้กำลังใจ: Ico24 Our Shangri-La, Ico24 ServiceMan, และ 8 คนอื่น.
สมาชิกที่ให้กำลังใจ
 
Facebook
Twitter
Google

บันทึกอื่นๆ

ความเห็น

ขนาดไฟล์เพิ่มขึ้นอีกเพียง ๓ จิกะไบต์โดยประมาณ แต่ลดเวลาลงจากเดิม ๔ ชั่วโมงเหลือ ครึ่งชั่วโมง

น่าจะเป็นการบริหารจัดการที่มีประสิทธิภาพมากกว่า เล็กลงไปนิดหน่อยแต่ภาระงานเพิ่มเป็น ๖ เท่าตัว

ผมเข้าใจว่าไฟล์รูปภาพในระยะขวบปีหลังของแชร์ (ย้อนหลังราว ๆ ๒ ปี) น่าจะเพิ่มขนาด (โดยรวม) ไม่มากนักเมื่อเทียบกับช่วงตั้งไข่ - ปีที่ ๓

ช่วงปีแรก ๆ เคยมีคนอัพรูปขนาด ๓ - ๔ เมกแปะไว้ในบันทึก แต่หลังจากเปลี่ยนเป็นแชร์รุ่นปัจจุบัน ขนาดของรูปถูกกำหนดไว้ไม่ให้เกิน ถ้าจำไม่ผิดน่าจะสักประมาณ ๘๐๐ กิโลไบต์ต่อไฟล์

จัดการเรื่องง่าย ๆ ก่อนผมมองว่าเป็นแนวทางที่ถูกต้องแล้วครับ เพราะบางทีเมื่อถึงเวลาหนึ่งเรื่องที่ว่าง่าย ๆ แบบนี้กลับเป็นเรื่องใหญ่ไปได้เช่นกัน

อย่างน้อยที่สุดตอนนี้ระยะเวลาที่ CPU Load/ Load จากการ backup ก็ถูกลดลงมาหลายเท่าตัวแล้ว

การดูแลระบบอย่างหนึ่งก็คือการใช้งานระบบ อันนี้ผมเห็นด้วยอย่างยิ่งครับ

^_^

เราเอง

Ico48
sdayu [IP: 172.30.235.157]
19 มีนาคม 2556 18:39
#85565

อ. ไม่ลอง xz เหรอฮะ

@Our Shangri-La ขอบคุณครับ

@Boat ผมคิดว่าในแง่ของอัตราของการบีบอัด ไม่น่าจะต่างกับ zip/gz/bz2/7z มากเท่าไหร่ และ ไม่ว่าอย่างไรการที่เพิ่มการบีบอัดเข้าไป ก็จะไปเพิ่มงานให้กับ CPU ซึ่งก็จะเพิ่มเวลาของการ backup ก็เลยไม่ได้ลองครับ

วิธีการบีบอัดแบบ xz นี้น่าจะเหมาะสมสำหรับการ backup ข้อมูล รูปแบบอื่นซึ่งต้องการลดขนาดให้ได้มากกว่า gz/bz2 และไม่ได้มีปัญหาเรื่องของ load ของระบบ แต่ความต้องการของระบบ share ในขณะนี้ มันสวนทางกันกับสิ่งที่ xz ให้อยู่ครับ :)

อาจารย์เขียนหนึ่งบันทึกนี่ได้ทั้งงานและความบันเทิงเลยนะคะ ขอชม (อีกครั้ง) 

และ"การออกทะเล"ของอาจารย์แต่ละครั้ง เป็นการเขียนแนวคิดที่มีประโยชน์นะคะ เป็นมุมมองที่คนอ่านสามารถเอาไปคิดเปรียบเทียบกับสิ่งที่ตัวเองทำได้ (อย่างน้อยก็พี่โอ๋คนหนึ่งที่เห็นด้วยเลย เรื่องการทำอะไรซ้ำๆแล้วหาวิธีทำให้เป็นระบบ เป็นแนวคิดที่จะบอกว่า เคยเห็นคนคิดไม่ได้มาแล้วนะคะ แล้วพอเราแนะนิดเดียวทำให้เขาได้งานจัดระบบเลย-เรียกว่าเป็นการสอนวิธีคิดค่ะ) 

จะบอกว่านี่คือประโยชน์ของการเขียนเล่าความคิดค่ะ ประสบการณ์ของแต่ละคนจะทำให้เรามีวิธีคิดที่ต่างๆกัน ทำให้การเรียนรู้ การสอนงานจะได้อะไรมากกว่าแค่การบอกให้ทำยังไง เทคนิคการทำยังไม่สำคัญเท่ากับแนวคิดในการหาวิธีทำนะคะ

สรุปว่าชอบค่ะ ชอบวิธีเขียนของคนที่เป็น Admin เพราะเขียนวิธีคิดด้วย...

ผมขออนุญาตนำความเห็นจากความเห็นท้ายรูปนี้ มาเก็บไว้ที่บันทึกนี้นะครับ เวลาหาจะได้หาได้สะดวกกว่านะครับ

##-------------------------------------------##

Ico48

1. จำเป็นไหมที่ต้องเก็บ file ไว้มากขนาดนี้ ดูแล้วสามารถย้อนหลังกลับไปได้ 14 วัน อาจจะเป็นเรื่องปกติ

แต่จะเก็บสัก 7 วันจะได้ไหม

เพราะถ้า ข้อมูลผิด ถึงแม้ว่าจะเก็บย้อนหลังไปกี่วันก็ ข้อมูลที่เก็บก็เป็นข้อมูลที่ผิด

แต่การเก็บหลายๆ วันแบบนี้ ถ้าเรารู้ตัวว่าข้อมูลที่เก็บผิด เรามีโอกาสที่จะกู้ข้อมูลที่ถูกต้องได้สูงกว่าเก็บน้อยวัน

แต่การ ย้อนหลังไปหลายๆ วัน มันจะคุ้มไหมกับการข้อมูลที่ผิดพลาด

2. จำเป็นไหมที่เก็บไว้เพียง file เดียว ทำไมไม่แบ่งเป็น file ย่อยๆ หลายๆ file

##------------------------------------##

เราเอง

ขอบคุณ คุณโอ๋-อโณ ครับ :) ขอบคุณ คุณ Our Shangri-La สำหรับ คำถามคุณภัทธ์ นะครับ ผมลองตอบดูแล้ว ปรากฏว่ามันยาว ... ก็เลยขอเอาไปเขียนเป็นบันทึกใหม่เลยก็แล้วกันครับ อยู่ที่ http://share.psu.ac.th/blog/etc/27815

ร่วมแสดงความเห็นในหน้านี้

ชื่อ:
อีเมล:
IP แอดเดรส: 35.172.195.49
ข้อความ:  
เรียกเครื่องมือจัดการข้อความ
   
ยกเลิก หรือ