Final Fantasy X/X-2 HD Remaster กับ Windows architecture

พอดีได้ข่าวว่า Final Fantasy X ได้ทำการ Port มาลง PC ก็เลยลองเล่นดูครับ เพราะภาคนี้ผมเล่นตอน PS2 ได้ประมาณ 30-40% แล้วก็ไม่ได้เล่นต่อเนื่องจากติดทำ Project จบสมัยเรียน เลยขายเครื่องทิ้งไปเพราะกลัวเรียนไม่จบ 🙂

แต่ที่เขียนถึงวันนี้คงพูดถึงเรื่อง Windows architecture กันนิดหน่อย

สืบเนื่องมาจากว่า ผมเล่นเกมนี้ไปได้ประมาณไม่นานเช่น 10-20นาที โปรแกรมก็ Crash ซึ่งมาจากขั้นตอนที่ไม่แน่นอน หรือเรียกว่า Random Crash นั่นเอง

ซึ่งการ Crash ของ Application นั้นก็หมายถึงการที่โปรแกรมหยุดทำงานด้วยสาเหตุใดสาเหตุหนึ่งแล้วโปรแกรมก็เด้งออกอัตโนมัติทิ้งให้เราอึ้งไปหลายวิ..

As User

จากการที่เราเป็น End User ของเกมนี้ก็ แน่นอนครับ ติดปัญหาเราก็ต้องลองหาใน Google ดูก็ก่อนเลย ซึ่งก็พบว่ามีหลายๆคนเจอปัญหาเดียวกัน

http://steamcommunity.com/app/359870/discussions/0/364042063114641626/
http://steamcommunity.com/app/359870/discussions/0/364042262885080038/
http://steamcommunity.com/app/359870/discussions/0/364042262879682906/

ซึ่งผมลองทำตาม workaround ต่างๆแต่ก็ยังไม่สำเร็จ เล่นไปสักแป๊บนึงเกมก็เด้งออกมาอีกเช่นเคย

As Developer

แต่ด้วยความที่เราก็ Developer ผมก็ตัดสินใจลอง Investigate ปัญหานี้ดูด้วยตัวเอง

สิ่งแรกที่ผมเห็นคือเวลามัน Crash ตัวไฟล์ CoreDump.dmp จะถูกสร้างขึ้นมา

coredump.png

ลองเปิดด้วย Visual Studio เพื่อทำการ Analyze Dump ไฟล์ได้ข้อมูลน่าสนใจตามนี้

dumpinfo

  1. Process นี้เป็น x86 ก็คือ 32 Bits
  2. Crash ที่เกิดขึ้นมี Exception เกี่ยวกับ Virtual Address หรือ Virtual Memory นั่นเอง

พอรู้แบบนี้ผมก็ลองเปิด Process Explorer ดูเลยครับว่าเวลาเล่นเกมนี้ มันใช้ Memory ขนาดไหน ปรากฎว่า…

ชัดเจนครับแค่เปิดเกมมา Virtual Memory ก็1.9GB แล้ว

screen

memreach

นี่คือสาเหตุของปัญหานี้ครับ..เนื่องจากว่า เกม(Process) นี้ถูก Compile ด้วย 32 Bits ทำให้สามารถใช้งาน Memory Space ได้ 2^32 bytes หรือประมาณคร่าวๆได้ 4GB (4,000,000KB โดยประมาณ)

แต่เนื่องจาก Windows Architect นั้นได้ทำการแบ่ง Memory ไว้เป็น 2 ส่วนคือ Kernel space กับ Application space (User space) อย่างละ 2GB

ซึ่งง่ายๆก็คือ Applicatoin จะใช้ได้ 2GB เท่านั้น ทำให้ถ้าใช้เกินโปรแกรมก็จะ Crash (ถ้าจัดการไม่ดี)

วิธีแก้ปัญหา

Windows นั้นได้มี Feature ที่เรียกว่า Large Address Aware ซึ่งทำให้ Application สามารถใช้งาน Memory ได้มากกว่า 2GB นั่นเอง

Tool ตัวนี้คือ Editbin.exe ซึ่งติดตั้งมากับ Microsoft Visual Studio อยู่แล้วครับ

พิมพ์ไปเลยครับตามนนี้

editbin /largeaddressaware “D:\Games\Final Fantasy X\FFX.exe”

editbin.png

เราก็จะได้ FFX.exe ตัวใหม่ที่ทำการเปิด Feature Large Address Aware แล้ว และเมื่อลองทดสอบดู Process ของเกมนี้ก็สามารถใช้ Memory ได้เกิน 2GB แล้ว

final_mem

และสุดท้ายตั้งแต่ผมแก้มาก็เล่นได้ 4-5 ชั่วโมงได้ไม่เจออาการ Crash/Freeze อีกเลยครับ 🙂

 

English:

For english guys (if any), I found one potential workaround to solve the random crash/freeze issues on FFX HD Remaster on PC. I think the issue is around memory reach limit of 32 Bits process which is 2GB for application space(from totally 4GB  – kernel and app/user space) which FFX has been built as 32 Bits app.

so once you configured the game with high graphic settings. it uses higher memory and might be able to trigger the issue more eaiser.

we can use the tool called “editbin.exe” which is the small utility to allow us to change the flag of the process which is “/largeaddressaware” that can help to incrase the app/user space of memory up to 3/4GB based on OS. but at least it will be higer than 2GB as system default.

you can find “editbin” from Visual Studio.

and after I applied this flag. I can play the game for 4-5 hours for 2 days without any crash. hope this can help for some.

 

HAPPY GAMING…

Advertisements

Continuous Deployment ของ Netflix

หลังจากที่ได้พูดถึงการทำ Continuous Deployment (CD) ของ Instragram ไปใน บทความที่ผ่านมา (link)

มาคราวนี้ทาง Netflix ซึ่งเป็น บริษัทที่ให้บริการด้านดูหนังและซีรีย์ออนไลน์ที่มีสมาชิกกว่า 75 ล้านคน

ทาง Engineer ของ Netflix ก็ได้มาแชร์ข้อมูลเกี่ยวกับการ Build http://techblog.netflix.com/2016/03/how-we-build-code-at-netflix.html

เราลองมาดูกันครับ

Netflix นั้นมีหรือ Workflow ตามรูปนี้

pasted image 0.png

ซึ่งกล่องสีขาวคือ Process ของการทำงานจากซ้ายมือไปขวามือ ส่วนสีฟ้าคือ Tools ที่ใช้

ก่อนที่จะลงรายละเอียดแต่ละขั้นตอนทาง Netflix ได้เน้นย้ำไว้ว่าสิ่งที่สำคัญที่ทำให้ Solution นี้เกิดขึ้นมาได้นั้นมาจาก

  1. วัฒนธรรมของบริษัท : ซึ่งก็คือ ความอิสระและความรับผิดชอบ เพื่อที่จะเน้นย้ำให้ทุกคนนั้นได้คิดถึง Solution หรือ Tool ที่ดีที่สุดในการแก้ปัญหาต่างๆได้อย่างเหมาะสม ซึ่ง Tool ที่ดีนั้นควรจะต้อง Add Value และช่วยลดขั้นตอนการทำงานด้วย ซึ่งทาง Engineers นั้นสามารถคิดหา Solution ได้เสมอและต้องคำนึงถึงการดูแลระบบด้วย
  2. Cloud : ทาง Netflix นั้นได้ทำการย้ายระบบจาก Data Center based ไปใช้ Amazon Webservice แทน
  3. Microservices : Netflix ได้เปลี่ยน architecture จากการทำงานด้วยระบบขนาดใหญ่ (monolithic) ไปเป็น Microservices แทน ซึ่ง Microservices นั้นคือการออกแบบให้ Services หรือ API นั้น เล็ก ไม่ซับซ้อน และเป็นอิสระต่อกัน เพื่อที่จะได้แก้ไขแต่ละ Service ได้ง่ายขึ้น

เริ่มจาก

  • Code ทำการ build และ test บนเครื่องของ Developer โดยใช้ Nebula (Tools ของ Netflix เอง)
  • Code Check-in : การ Commit Code เข้า Master branch โดยใช้ Git
  • Continuous Integration : ใช้ Jenkins ในการสั่งให้ Nebular ทำงาน ซึ่งสิ่งที่เกิดขึ้นในขั้นตอนนี้จะประกอบด้วย การ build, test, และการทำ package ที่ไว้ใช้สำหรับการ deploy
  • Bake : ในการ deploy ของทาง Netflix นั้นจะเริ่มจากการ สร้าง Image ของเครื่องใหม่บน Amazon  โดย Image นั้นได้มีการติดตั้งระบบพื้นฐานไว้แล้วเช่น Linux, มี Tools หรือ services ต่างๆพร้อมที่จะใช้สำหรับการติดตั้ง package ใหม่
  • Deployment (Deploy จนถึง Live) : ทาง Netflix ใช้ Spinnaker ช่วยในการทำ pipeline ในการ deploy ต่างๆเช่น เครื่อง Test การจัดการเกี่ยวกับการ deploy หลายๆทวีปพร้อมกัน การทำ canary release เพื่อให้ users ทดลองใช้

สุดท้ายนี้ Netflix ยังได้พูดถึงความท้าทายที่ทางทีมกำลังแก้ไขด้วย เช่น

  1. ปัญหาด้าน dependnecies ของ Java ซึ่งทางทีมก็ได้ปรับปรุงให้ดีขั้นแล้ว
  2. ขั้นตอนของ Bake ให้เวลาเยอะไป ซึ่งปัจจุบันขั้นตอนหลังจาก Code Check-in จน Deploy เสร็จนั้นใช้เวลา 16 นาที แต่เวลา 7 นาทีนั้นใช้ในขั้นตอน Bake ซึ่งเป็น 44% ของเวลาทั้งหมด

มาดู Continuous Deployment ของ Instagram กัน

เมื่อต้นเดือนเมษายน ทาง Engineer ของ Instagram ได้เขียนบนความของการทำ Continuous Deployment ภายในระบบของเค้า http://engineering.instagram.com/posts/1125308487520335/continuous-deployment-at-instagram

เราจะมาดูกันว่ามีอะไรน่าสนใจบ้าง [ผมแปลแบบสรุปไปด้วยนะครับ ดังนั้นอาจจะไม่ใช่การแปลแบบแป๊ะๆ]

ทำไปทำไม?

Continuous Deployment นั้นมีข้อดีมากมายๆนะครับ ใครไม่รู้จักคำนี้และทำงาน Software Development ที่มีระบบขนาดกลาง/ใหญ่ (ที่มี Developers มากกว่า 10 ละกัน) ควรจะลองศึกษาดู

  1. ทำให้ Developers/Engineers ทำงานได้เร็วขึ้น สามารถที่จะแก้ไขอะไรได้รวดเร็วมากขึ้น
  2. ทำให้ช่วยในการหาข้อผิดพลาดที่เกิดจากการแก้ไขตัวระบบได้เร็วขึ้น จากที่จะต้องมาดูสิ่งที่แก้ไขที่มีเยอะแยะ ก็มาดูแค่รายครั้งที่มีการ Deploy ในแค่ละครั้ง
  3. สิ่งที่ Commit แล้วมีปัญหาก็จะเจอได้รวดเร็วและยังแก้ได้เร็วด้วย

การนำไปใช้

ทาง Instagram นั้นใช้วิธี iterative approach ก็คือไม่ใช้ว่าทำระบบที่เดียวเสร็จแล้วใช้งานทันที แต่จะใช้การค่อยๆพัฒนาทีละจุดไปเรื่อยๆจนกระทั่งเสร็จสมบูรณ์

ก่อนหน้านี้เป็นยังไง

ก่อนที่ทาง Instagram จะมี Continuous Deployment นั้น Engineer จะใช้การ Deploy ตามใจและเวลาที่จะมีการแก้ไข รวมถึงต้องรู้การเช็ค Log และเริ่มการ Deploy ที่ละเครื่องเพื่อทำการทดสอบก่อนที่จะ Deploy ไปที่เครื่อง Servers ที่เหลือ

การทดสอบ/เทส

เริ่มจากการเพิ่มการเทสซึ่งเป็น Script ง่ายๆที่ทาง Engineer ต้องทำจากที่ต้องทำบนเครื่องที่ตั้งใจจะลงบน Production ก็เปลี่ยนมาเป็นทำการ Deploy ที่เครื่อง Canary Machine(เครื่องสำหรับให้ users ทดลองใช้)

จากนั้นมีการสร้างเครื่องที่ทำการทดสอบจาก Git – Master โดยใช้ Jenkins เมื่อเทสของ version ไหนผ่านก็จะมีการแนะนำว่าควรใช้ version นั้นแทนที่จะเป็น version ล่าสุด

การทำงานอัตโนมัติ

เนื่องจากระบบข้างบนแล้ว สิ่งที่ยังเหลือว่าจะต้องให้คนตัดสินใจก็คือ

  1. จะเอา version ไหนไปใช้ในการ Deploy – ซึ่งทาง Instagram ก็เลือกใช้ version ที่ผ่านการทดสอบและมีการเปลี่ยนแปลงไม่เกิน 3 commits
  2. การ Deploy สำเร็จหรือไม่ – หลักการก็คือถ้าไม่สามารถ Deploy ไปที่ servers ได้ด้วยอัตรา 1% จะถึงว่าไม่สำเร็จ

ปัญหา

หลังจากที่ทาง Instagram ได้ทำมาก็พบว่ามีปัญหาใหญ่ๆคือ

เทสไม่ผ่าน

หลายๆครั้งที่ทาง Engineer ได้พบว่ามีการแก้ไข software ที่ทำให้การเทสไม่ผ่าน ซึ่งทำให้ไม่สามารถ Deploy ได้ ซึ่งการแก้ไขนั้นต้องทำการ revert แบบ Manual รวมถึงการเทสที่ใช้เวลานานและไม่ค่อยเสถียร ซึ่งทาง Engineer ก็ได้ทำการแก้ไขให้เทสได้เร็วขึ้นเป็น 5 นาทีจาก 15 นาที

สิ่งที่จะ Deploy

ทาง Instagram พบว่าสิ่งที่จะต้อง Deploy มีมากในคิว เนื่องจากว่าระบบ Canary สามารถดักจับปัญหาได้(ทั้งปัญหาจริง และบั๊ก) ซึ่งทำให้การ Deploy หยุด และต้องมีการแก้ไขด้วย Engineer เพื่อให้ระบบ Automation ทำงานต่อได้ ซึ่งทำให้เกิดการล่าช้าของการ Deploy สิ่งใหม่ๆ ซึ่งทาง Engineerได้แก้ไขปัญหานี้ด้วยการปรับปรุงเงื่อนไขในการทำ Automation deploy ให้ทำงานได้ดีมากขึ้น

หลักการที่แนะนำ

ทาง Instagram ยังได้แนะนำว่าถ้าอยากได้ระบบแบบของเค้า ให้ลองตามนี้

  1. การเทส

    ระบบเทสต้องเร็วและครอบคลุม แต่ไม่จำเป็นต้องสมบูรณ์ และต้องถูกใช้งานบ่อยๆ ทั้งตอน Code Review, ก่อนการ Deploy และหลังจาก Deploy

  2. Canary

    ต้องมีการทำ automated canary เพื่อที่จะป้องกันไม่ให้มีการ commit ที่ไม่ดีเข้าไปอยู่ในสิ่งที่จะ Deploy ลงบน Server ทุกเครื่อง

  3. Automated Test สำหรับการทำงานปกติ

    ไม่จำเป็นต้องมี automate ทั้งหมด แต่เฉพาะสิ่งที่สำคัญจริงๆและเป็นสิ่งที่เกิดขึ้นในเหตุการณ์ปกติ

  4. ทำให้คนรู้สึกมั่นใจ

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

  5. คิดไว้เลยว่าต้องเจอการ Deploy ไม่สำเร็จ

    อาจจะมีโอกาสที่จะมี version ที่ไม่ดีหลุดออกไปบน Production ซึ่งเป็นเรื่องที่ยอมรับได้ แต่ระบบจะต้องตรวจเจอได้เร็วและสามารถแก้ไข้แต่เร็วด้วย

ขั้นต่อไป

  1. ทำให้เร็วยิ่งขึ้น
  2. เพิ่ม Canary
  3. เพิ่มข้อมูล
  4. ปรับปรุงการดักจับข้อผิดพลาด