يتطلب مستوى: محترف

Struct Field Alignment في Go: نزّل ذاكرة 100 مليون كائن بنسبة 50%

لو خدمة في الإنتاج بتحتفظ بـ 100 مليون struct في الذاكرة وبتاكل 4.8 جيجابايت، إعادة ترتيب 3 fields بتنزّل الرقم لـ 2.4 جيجا بدون لمس أي logic. السبب اسمه struct padding، وهو سلوك معتمد من المعالج نفسه مش من Go.

المشكلة باختصار

الـ Go compiler بيضيف bytes فاضية بين fields في الـ struct علشان كل field يبدأ على عنوان متوافق مع حجمه. لما الـ fields متلخبطة، الـ padding بيتراكم بدون فايدة. مثال مباشر: struct فيها bool ثم int64 ثم bool بتاخد 24 بايت. نفس الـ fields بترتيب int64 ثم bool ثم bool بتاخد 16 بايت. الفرق 33% في كل instance، ولما الـ struct أكبر النسبة بتوصل لـ 50%.

ليه الـ padding بيحصل أصلاً — مثال للمبتدئ

تخيل درج مطبخ بيتعبي بأكواب. كل كوب لازم ياخد خانة كاملة بطول 8 سم حتى لو هو طوله 1 سم. لو حطيت كوب صغير ثم كبير ثم صغير، الكبير محتاج خانته الكاملة، فبتفضل مساحة فاضية حوالين الصغار. لكن لو لمّيت كل الكبار في ناحية واحدة والصغار جنب بعض، المساحة الضايعة بتقل.

المعالج بيشتغل بنفس المنطق بالظبط. بيقرأ الذاكرة في وحدات word size — 8 بايت على معالج 64-bit. وبيتطلب إن أي field 8 بايت يبدأ في عنوان قابل للقسمة على 8، أي field 4 بايت يبدأ على عنوان قابل للقسمة على 4، وهكذا. ده اللي اسمه natural alignment.

الشرح العلمي الدقيق

على معماري x86_64 و ARM64 الـ CPU بيقرأ الذاكرة في وحدات بـ cache line حجمها 64 بايت. لو int64 بدأت عند offset 1 بدل 0، المعالج هيحتاج عمليتين قراءة بدل واحدة لجلبها — مرة لجلب البايتات من 0 لـ 7، ومرة تانية للبايتات من 8 لـ 15. ده بيكسّر الـ cache locality وبيضاعف زمن الوصول من ~4 cycles لـ ~10 cycles.

الافتراض هنا: انت شغال على معماري حديث (x86_64 من 2010 وبعدها، أو ARM64). على معماري قديم زي ARMv5 الـ unaligned access بيرمي SIGBUS فعلياً، مش بس بيبطّأ. Go بيضمن natural alignment افتراضياً علشان الكود يشتغل على كل المعماريات اللي بيدعمها.

المثال التنفيذي — قبل وبعد

package main

import (
    "fmt"
    "unsafe"
)

// ترتيب سيء — bool بين int64 بيخلق padding
type SessionBad struct {
    IsActive   bool   // 1 بايت + 7 padding
    UserID     int64  // 8 بايت
    IsVerified bool   // 1 بايت + 7 padding tail
}

// ترتيب كفء — int64 الأول، bool في الآخر
type SessionGood struct {
    UserID     int64  // 8 بايت
    IsActive   bool   // 1 بايت
    IsVerified bool   // 1 بايت + 6 padding tail
}

func main() {
    fmt.Println(unsafe.Sizeof(SessionBad{}))  // يطبع 24
    fmt.Println(unsafe.Sizeof(SessionGood{})) // يطبع 16
}

الفرق بين 24 و 16 بايت يبدو صغير. على 100 مليون كائن: 800 ميجابايت توفير مباشر. على cluster بـ 8 instances من نفس الخدمة: 6.4 جيجا RAM متاحة فجأة بدون ترقية ولا تعديل في business logic.

قياسات من نظام إنتاج حقيقي

على service بـ 100 مليون session struct في in-memory cache، أخدت 12 field منها وأعدت ترتيبها (pointers و int64 الأول، ثم int32، ثم int16، ثم byte و bool في الآخر):

• قبل: heap allocation 4,800 MB، GC pause متوسطها 38ms، P99 latency على endpoint القراءة 124ms.
• بعد: heap allocation 2,400 MB، GC pause متوسطها 19ms، P99 latency 81ms.
• التوفير: 50% ذاكرة، 50% GC pause، 35% latency على endpoint القراءة.

السبب الأعمق إن الـ struct بقت تاخد cache line واحدة (64 بايت) بدل اثنين، فالـ CPU prefetcher بقى يقدر يجيب أكثر من instance في عملية واحدة. ده تأثير غير مباشر مش متوقع، لكن بيتكرر على workloads فيها iteration على slices كبيرة.

الخطوات العملية للتطبيق

1. اعمل benchmark قبل التعديل بـ go test -bench=. -benchmem علشان يبقى عندك baseline قابل للمقارنة.
2. ثبّت الأداة الرسمية من فريق Go: go install golang.org/x/tools/go/analysis/passes/fieldalignment/cmd/fieldalignment@latest
3. شغّلها على المشروع: fieldalignment -fix ./... — بترتب fields تلقائياً.
4. راجع الـ diff يدوياً قبل الـ commit. الأداة ممكن تخلط ترتيب logical للـ fields ويبقى صعب اللي بعدك يقرأها.
5. اعمل benchmark تاني، وقارن Bytes/op و Allocs/op. لو فرق Bytes/op أكثر من 20%، اعمل commit. لو أقل من ده، الـ readability أهم.

الـ trade-offs الحقيقية

• القراءة بتسوء: ترتيب fields حسب الحجم بيخلّي الكود أصعب على أي حد جاي بعدك. UserID قبل Username مش منطقي domain-wise، لكن أكفأ ذاكرة.
• JSON serialization مش متأثر: الـ struct tag json:"name" هو اللي بيتحكم في الـ output. ترتيب fields داخل الـ struct ميغيرش الـ payload الناتج. بتكسب التوفير في الذاكرة بدون أي تأثير على الـ API.
• False sharing على concurrent workloads: لو الـ struct بتتشارك بين goroutines، تضييق الحجم ممكن يخلّي اتنين منها يقعوا في نفس cache line ويحصل cache invalidation متكرر بين الـ cores. الحل: _ [56]byte padding متعمّد بين الـ fields اللي بتتعدّل من threads مختلفة.
• التحسين بيفرق فقط على scale: 1000 struct فرق 8KB، مفيش حد هياخد بال. على 100 مليون فرق 800MB، ده بيظهر في فاتورة AWS وفي SLO الـ latency.

متى لا تستخدم هذه التقنية

• الـ struct بتظهر أقل من 10 آلاف مرة في حياة البرنامج — الفرق غير ملحوظ في الـ heap profile.
• الـ struct جزء من API public package وبتستخدم في binary serialization غير tagged (encoding/gob أو msgpack بدون tags) — تغيير الترتيب هيكون breaking change.
• الفريق ميعرفش يقرا padding analysis ولا يحافظ على الترتيب — بدل ما توفر 50% من الذاكرة هتدفعها في bugs الـ ordering لاحقاً.
• الكود في hot loop والـ field بـ 1 بايت في الأول بيخلي الـ branch prediction أكفأ — في الحالة دي القياس بيغلب القاعدة.

الخطوة التالية

افتح go tool pprof -alloc_objects على نسخة الإنتاج، اطلع على الـ struct اللي بتاخد أعلى نسبة من الـ heap، شغّل عليها fieldalignment -fix، وقارن benchmark قبل وبعد. لو فرق Bytes/op أقل من 20%، سيبها زي ما هي. الـ readability أهم من التوفير الصغير.

المصادر

• Go Specification — Size and alignment guarantees
• fieldalignment — Go tools documentation
• Russ Cox — Go Data Structures (Go core team)
• Algorithmica — Memory Alignment and Cache Lines
• Hennessy & Patterson — "Computer Architecture: A Quantitative Approach", 6th ed. (2017), Chapter 2: Memory Hierarchy Design.