🔵 عنوان مقاله
BillionMail 3.0: Open Source Email Marketing Platform
🟢 خلاصه مقاله:
مقاله به بررسی یک سرویس سرور ایمیل و ارسال نامهخبری/ایمیل میپردازد که با زبان برنامهنویسی Go کار میکند. این نرمافزار تحت لیسانس AGPL منتشر شده است. کد منبع این پروژه نیز در GitHub قابل دسترسی است، که این امکان را برای توسعهدهندگان فراهم میکند تا در پروژه مشارکت یا آن را تغییر دهند. استفاده از زبان Go این اطمینان را به کاربران میدهد که نرمافزار با کارایی بالا و عملکرد قابل اعتمادی ارائه دهد.
🟣لینک مقاله:
https://golangweekly.com/link/170948/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
BillionMail 3.0: Open Source Email Marketing Platform
🟢 خلاصه مقاله:
مقاله به بررسی یک سرویس سرور ایمیل و ارسال نامهخبری/ایمیل میپردازد که با زبان برنامهنویسی Go کار میکند. این نرمافزار تحت لیسانس AGPL منتشر شده است. کد منبع این پروژه نیز در GitHub قابل دسترسی است، که این امکان را برای توسعهدهندگان فراهم میکند تا در پروژه مشارکت یا آن را تغییر دهند. استفاده از زبان Go این اطمینان را به کاربران میدهد که نرمافزار با کارایی بالا و عملکرد قابل اعتمادی ارائه دهد.
🟣لینک مقاله:
https://golangweekly.com/link/170948/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Billionmail
a Free MailServer, NewsLetter and Marketing tools
Set up your own open-source mail server with BillionMail for free and start using a powerful SMTP mail server for your emails.
❤2
🔵 عنوان مقاله
Unregistry: Push Docker Images Directly to Remote Servers
🟢 خلاصه مقاله:
این مقاله به بررسی یک رجیستری تصویر کانتینر سبک وزن میپردازد که قادر است تصاویر را مستقیماً از ذخیرهسازی دیمون Docker خود ذخیره و ارائه دهد. استفاده از ذخیرهسازی دیمون Docker برای ریجستری، سرعت و کاهش تاخیر را به همراه دارد، زیرا نیازی به انتقال تصاویر از طریق شبکه نیست. حتی یکی از خالقان Docker نیز این طرح را تحسین کرده و آن را جالب توصیف کرده است. این مدل میتواند به ویژه در محیطهایی که سرعت و راحتی توسعهدهندگان اولویت دارد، مفید باشد.
🟣لینک مقاله:
https://golangweekly.com/link/170944/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Unregistry: Push Docker Images Directly to Remote Servers
🟢 خلاصه مقاله:
این مقاله به بررسی یک رجیستری تصویر کانتینر سبک وزن میپردازد که قادر است تصاویر را مستقیماً از ذخیرهسازی دیمون Docker خود ذخیره و ارائه دهد. استفاده از ذخیرهسازی دیمون Docker برای ریجستری، سرعت و کاهش تاخیر را به همراه دارد، زیرا نیازی به انتقال تصاویر از طریق شبکه نیست. حتی یکی از خالقان Docker نیز این طرح را تحسین کرده و آن را جالب توصیف کرده است. این مدل میتواند به ویژه در محیطهایی که سرعت و راحتی توسعهدهندگان اولویت دارد، مفید باشد.
🟣لینک مقاله:
https://golangweekly.com/link/170944/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
GitHub
GitHub - psviderski/unregistry: Push docker images directly to remote servers without an external registry
Push docker images directly to remote servers without an external registry - psviderski/unregistry
❤1👍1
🔵 عنوان مقاله
makefile-graph: Turn a Makefile into a Graph
🟢 خلاصه مقاله:
این مقاله درباره ابزاری بحث میکند که هم به عنوان کتابخانه و هم ابزار CLI قابل استفاده است و برای تحلیل Makefileها طراحی شده است. این ابزار، وابستگیهای میان مختلف هدفهای تعیین شده در Makefileها را میخواند و آنها را به شکل گراف درآورده تا توسط ابزار گرافیکی Graphviz dot نمایش داده شود. ویژگی دوگانه بودن این ابزار به همراه قابلیت نمایش تصویری، تحلیل و بهینهسازی فرایندهای ساخت نرمافزار را برای توسعهدهندگان آسانتر میکند.
🟣لینک مقاله:
https://golangweekly.com/link/170946/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
makefile-graph: Turn a Makefile into a Graph
🟢 خلاصه مقاله:
این مقاله درباره ابزاری بحث میکند که هم به عنوان کتابخانه و هم ابزار CLI قابل استفاده است و برای تحلیل Makefileها طراحی شده است. این ابزار، وابستگیهای میان مختلف هدفهای تعیین شده در Makefileها را میخواند و آنها را به شکل گراف درآورده تا توسط ابزار گرافیکی Graphviz dot نمایش داده شود. ویژگی دوگانه بودن این ابزار به همراه قابلیت نمایش تصویری، تحلیل و بهینهسازی فرایندهای ساخت نرمافزار را برای توسعهدهندگان آسانتر میکند.
🟣لینک مقاله:
https://golangweekly.com/link/170946/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
GitHub
GitHub - dnaeon/makefile-graph: Turn your Makefile into a graph
Turn your Makefile into a graph. Contribute to dnaeon/makefile-graph development by creating an account on GitHub.
❤1👍1
خیلی جالبه، سازنده flask (از فریمورک های معروف پایتون) خودش پیشنهاد میکنه پروژه های جدید بکندی رو با گولنگ بنویسید!
https://lucumr.pocoo.org/2025/6/12/agentic-coding/
I've evaluated agent performance across different languages my workload, and if you can choose your language, I strongly recommend Go for new backend projects
https://lucumr.pocoo.org/2025/6/12/agentic-coding/
I've evaluated agent performance across different languages my workload, and if you can choose your language, I strongly recommend Go for new backend projects
👍9❤5🍾2
🔵 عنوان مقاله
JSON Evolution in Go: From V1 to V2
🟢 خلاصه مقاله:
با ارائه بسته JSON v2 در نسخه 1.25 زبان برنامه نویسی Go که قرار است در ماه آگوست منتشر شود، ویژگیهای جدید و بهبودهای قابل توجهی معرفی شدهاند. این بهروزرسانی شامل افزودن برچسبهای زمینهی جدید، تغییرات در تنظیمات پیشفرض مارشالکردن، استفاده از رابطهای برنامهنویسی API های جریانی، و دیگر امکانات است که برای تسهیل کار با دادههای JSON در Go طراحی شدهاند. یکی از مهمترین پیشرفتها، بهبود قابل توجه در فرآیند آنمارشالکردن است که تا ده برابر سریعتر از نسخهای قبلی گزارش شده است، که این باعث افزایش کارایی و کاهش مصرف منابع در برنامههای کاربردی میشود.
🟣لینک مقاله:
https://golangweekly.com/link/170927/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
JSON Evolution in Go: From V1 to V2
🟢 خلاصه مقاله:
با ارائه بسته JSON v2 در نسخه 1.25 زبان برنامه نویسی Go که قرار است در ماه آگوست منتشر شود، ویژگیهای جدید و بهبودهای قابل توجهی معرفی شدهاند. این بهروزرسانی شامل افزودن برچسبهای زمینهی جدید، تغییرات در تنظیمات پیشفرض مارشالکردن، استفاده از رابطهای برنامهنویسی API های جریانی، و دیگر امکانات است که برای تسهیل کار با دادههای JSON در Go طراحی شدهاند. یکی از مهمترین پیشرفتها، بهبود قابل توجه در فرآیند آنمارشالکردن است که تا ده برابر سریعتر از نسخهای قبلی گزارش شده است، که این باعث افزایش کارایی و کاهش مصرف منابع در برنامههای کاربردی میشود.
🟣لینک مقاله:
https://golangweekly.com/link/170927/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
antonz.org
JSON evolution in Go: from v1 to v2
Reviewing the key changes in json/v2.
👍2❤1
🔵 عنوان مقاله
Cloud66's Go Stack in 2025
🟢 خلاصه مقاله:
مقاله به بررسی انتخابهای تیم برنامهنویسی Go در مورد بستههای مختلفی که فرایند توسعه آنها را بهینه کرده است میپردازد. این بخشها شامل مدیریت تنظیمات، چهارچوب CLI، چارچوب HTTP، ORM و تزریق وابستگی و مدیریت چرخه حیات میباشد. هدف از انتخاب این ابزارها، افزایش کارایی و نگهداری آسانتر سرویسهای وب، مدیریت موثر تر تنظیمات و محیطهای برنامه، و همچنین بهبود قابلیت توسعه و نگهداری پایگاههای داده و کدبیس است.
🟣لینک مقاله:
https://golangweekly.com/link/170929/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Cloud66's Go Stack in 2025
🟢 خلاصه مقاله:
مقاله به بررسی انتخابهای تیم برنامهنویسی Go در مورد بستههای مختلفی که فرایند توسعه آنها را بهینه کرده است میپردازد. این بخشها شامل مدیریت تنظیمات، چهارچوب CLI، چارچوب HTTP، ORM و تزریق وابستگی و مدیریت چرخه حیات میباشد. هدف از انتخاب این ابزارها، افزایش کارایی و نگهداری آسانتر سرویسهای وب، مدیریت موثر تر تنظیمات و محیطهای برنامه، و همچنین بهبود قابلیت توسعه و نگهداری پایگاههای داده و کدبیس است.
🟣لینک مقاله:
https://golangweekly.com/link/170929/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Cloud 66
Our Golang Stack in 2025
Build, deploy and manage your applications on any cloud or your own servers.
❤1
🔵 عنوان مقاله
'Go Should Be More Opinionated'
🟢 خلاصه مقاله:
یک توسعهدهنده پیشنهاد داده است که زبان برنامهنویسی Go باید در مورد چیدمان برنامهها نظریات مشخصتری داشته باشد. این بیانیه بیانگر نظر عمومی توسعهدهندگانی است که خواهان راهنماییها و استانداردسازیهای بیشتر در معماری برنامهها هستند تا تنظیم پروژهها را بهبود ببخشد و نگهداری کد را آسانتر کند. مطالب مربوط به معماری و چیدمان برنامهها همواره در خبرنامههای موضوعی محبوبیت داشته و باعث شده است که جامعه توسعهدهندگان در مورد بهترین شیوههای ممکن و جهتگیریهای آتی برنامهنویسی گفتگو و تبادل نظر کنند.
🟣لینک مقاله:
https://golangweekly.com/link/170932/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
'Go Should Be More Opinionated'
🟢 خلاصه مقاله:
یک توسعهدهنده پیشنهاد داده است که زبان برنامهنویسی Go باید در مورد چیدمان برنامهها نظریات مشخصتری داشته باشد. این بیانیه بیانگر نظر عمومی توسعهدهندگانی است که خواهان راهنماییها و استانداردسازیهای بیشتر در معماری برنامهها هستند تا تنظیم پروژهها را بهبود ببخشد و نگهداری کد را آسانتر کند. مطالب مربوط به معماری و چیدمان برنامهها همواره در خبرنامههای موضوعی محبوبیت داشته و باعث شده است که جامعه توسعهدهندگان در مورد بهترین شیوههای ممکن و جهتگیریهای آتی برنامهنویسی گفتگو و تبادل نظر کنند.
🟣لینک مقاله:
https://golangweekly.com/link/170932/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
eltonminetto.dev
Go should be more opinionated
One of the perks of being a Google Developer Expert is the incredible opportunities it provides.
❤3
🔵 عنوان مقاله
♟️ Running a Million-Board Chess MMO in a Single Process
🟢 خلاصه مقاله:
این مقاله به توضیح دقیقی پرداخته است در رابطه با نحوه ساخت یک بازی شطرنج چندنفره بزرگ توسط یک توسعهدهنده بازی، که با استفاده از زبان برنامهنویسی Go در پشتصحنه، بدون هیچ مشکلی در عملکرد، انجام شده است. توسعهدهنده این فرایند را از طریق ویدیویی در یوتیوب به اشتراک گذاشته که هم آموزشی است و هم نمایشی از کاربرد Go در توسعه بازیهای زمان-واقعی پیچیده. عبارت "Go Blue" به استفاده و حمایت از زبان Go در جامعه فناوری یا بازیسازی اشاره دارد.
🟣لینک مقاله:
https://golangweekly.com/link/171243/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
♟️ Running a Million-Board Chess MMO in a Single Process
🟢 خلاصه مقاله:
این مقاله به توضیح دقیقی پرداخته است در رابطه با نحوه ساخت یک بازی شطرنج چندنفره بزرگ توسط یک توسعهدهنده بازی، که با استفاده از زبان برنامهنویسی Go در پشتصحنه، بدون هیچ مشکلی در عملکرد، انجام شده است. توسعهدهنده این فرایند را از طریق ویدیویی در یوتیوب به اشتراک گذاشته که هم آموزشی است و هم نمایشی از کاربرد Go در توسعه بازیهای زمان-واقعی پیچیده. عبارت "Go Blue" به استفاده و حمایت از زبان Go در جامعه فناوری یا بازیسازی اشاره دارد.
🟣لینک مقاله:
https://golangweekly.com/link/171243/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
eieio.games
Running a million-board chess MMO in a single process · eieio.games
How one million chessboards works
❤3🔥2
🔴قابلیت Container-aware GOMAXPROCS ویژگی های جدید گولنگ نسخه 1.25
در Go 1.25، رفتار پیشفرض
* اگر quota عددی کسری ainer/cgroup است:
🧠 چه تغییری ایجاد شده؟
1. پیشفرض هوشمندانه در محیطهای container
قبل از Go 1.25، اگر داخل یک کانتینر با CPU quota=1 اجرا میکردید،
حالا این مقدار با توجه به quota واقعی کانتینر تنظیم میشود:
* اگر quota برابر 1 باشد،باشد (مثلاً 2.3)، با گرد کردن به بالا مقدار 3 میگیرد
* حداقل مقدار، حتی برای quota=1 هم 2 خواهد بود، مگر اینکه affinity یا CPU فیزیکی کمتر باشد
2. بروزرسانی پویا در حین اجرای برنامه
اگر پس از شروع برنامه quota تغییر کند (مثلاً از Kubernetes)، runtime بهصورت دورهای (معمولاً هر ثانیه) مقدار
3. امکان غیرفعالسازی
* اگر مقدار
* همچنین میتوانید با تنظیم
- 📚 مثال واقعی
فرض کنید در Kubernetes اجرای زیر را داریم:
درون برنامه:
خروجی قبل از Go 1.25:
در Go 1.25:
اگر quota = 2.3 باشد، مقدار:
و اگر quota = 1، ولی نود بزرگتر باشد، مقدار:
حالا اگر حجم CPU محدودیت افزایش یابد، مثلاً از 1 به 2، مقدار نیز بدون نیاز به ریاستارت برنامه بروزرسانی میشود
برای بازگرداندن به حالت پیشفرض پس از تنظیم دستی، میتوانید بنویسید:
✅ چرا این مهم است؟
1. هماهنگی با منابع کانتینری – دیگر نیازی به تعیین دستی یا بسته شدن برنامه ندارید.
2. کاهش throttling – با منطبق شدن با quota، احتمال deschedule شدن threadها و تأخیر کاهش پیدا میکند .
3. کارایی بهتر GC و scheduler – هرچه
4. مناسب برای Kubernetes و سرورلس – نیازی نیست ابزار اضافی مثل
✳️ جمعبندی
در Go 1.25 بهصورت هوشمندانه
➖➖➖➖➖➖➖➖
👑 @gopher_academy
در Go 1.25، رفتار پیشفرض
GOMAXPROCS
(تعداد هستههای مجازی که به اجرای goroutineها اختصاص داده میشود) اکنون آگاه به محدودیتهای cont GOMAXPROCS
هم شده 1* اگر quota عددی کسری ainer/cgroup است:
🧠 چه تغییری ایجاد شده؟
1. پیشفرض هوشمندانه در محیطهای container
قبل از Go 1.25، اگر داخل یک کانتینر با CPU quota=1 اجرا میکردید،
GOMAXPROCS
برابر با تعداد کل CPU های میزبان (مثلاً 8 یا 32) بود.حالا این مقدار با توجه به quota واقعی کانتینر تنظیم میشود:
* اگر quota برابر 1 باشد،باشد (مثلاً 2.3)، با گرد کردن به بالا مقدار 3 میگیرد
* حداقل مقدار، حتی برای quota=1 هم 2 خواهد بود، مگر اینکه affinity یا CPU فیزیکی کمتر باشد
2. بروزرسانی پویا در حین اجرای برنامه
اگر پس از شروع برنامه quota تغییر کند (مثلاً از Kubernetes)، runtime بهصورت دورهای (معمولاً هر ثانیه) مقدار
GOMAXPROCS
را بهروز میکند .3. امکان غیرفعالسازی
* اگر مقدار
GOMAXPROCS
دستی تنظیم شده یا در env مشخص شده باشد، این رفتار جدید غیرفعال میشود .* همچنین میتوانید با تنظیم
Gontainermaxprocs=0
یا updatemaxprocs=0
رفتار را خاموش یا بروزرسانی پویا را متوقف کنید ([tip.golang.org][1]).- 📚 مثال واقعی
فرض کنید در Kubernetes اجرای زیر را داریم:
kubectl run go-app --image=golang:1.25rc1 \
--limits="cpu=1"
درون برنامه:
fmt.Println("GOMAXPROCS:", runtime.GOMAXPROCS(0))
خروجی قبل از Go 1.25:
GOMAXPROCS: 8 // مثلاً روی یک نود ۸ هستهای
در Go 1.25:
GOMAXPROCS: 1
اگر quota = 2.3 باشد، مقدار:
GOMAXPROCS: 3
و اگر quota = 1، ولی نود بزرگتر باشد، مقدار:
GOMAXPROCS: 2
حالا اگر حجم CPU محدودیت افزایش یابد، مثلاً از 1 به 2، مقدار نیز بدون نیاز به ریاستارت برنامه بروزرسانی میشود
برای بازگرداندن به حالت پیشفرض پس از تنظیم دستی، میتوانید بنویسید:
runtime.SetDefaultGOMAXPROCS()
✅ چرا این مهم است؟
1. هماهنگی با منابع کانتینری – دیگر نیازی به تعیین دستی یا بسته شدن برنامه ندارید.
2. کاهش throttling – با منطبق شدن با quota، احتمال deschedule شدن threadها و تأخیر کاهش پیدا میکند .
3. کارایی بهتر GC و scheduler – هرچه
GOMAXPROCS
کمتر به real CPU نزدیکتر باشد، مصرف حافظه و context switch کاهش مییابد 4. مناسب برای Kubernetes و سرورلس – نیازی نیست ابزار اضافی مثل
automaxprocs
استفاده شود؛ همین رفتار در runtime تعبیهشده کافی است .✳️ جمعبندی
در Go 1.25 بهصورت هوشمندانه
GOMAXPROCS
را بر اساس محدودیت واقعی CPU در کانتینر تنظیم و بروزرسانی میکند. این ویژگی باعث اجرای بهینهتر برنامهها در Kubernetes و محیطهای مشابه میشود و نیاز به تنظیمات اضافی را حذف میکند. اگر در پروژه شما محدودیت CPU تعریف نکردهاید یا به رفتار پیشین نیاز دارید، میتوانید با GODEBUG
یا runtime.SetDefaultGOMAXPROCS()
کنترل کنید.➖➖➖➖➖➖➖➖
👑 @gopher_academy
❤2👍1🎉1
🔵 عنوان مقاله
The Evolution of Caching Libraries in Go
🟢 خلاصه مقاله:
توسعهدهنده کتابخانه کش Otter، به بررسی تاریخچه کتابخانههای کش در زبان برنامهنویسی Go پرداخته است. او مشکلاتی که توسعهدهندگان در گذشته با آن روبرو بودهاند و دلایل به وجود آمدن Otter را شرح داده است. کتابخانههای کش قبلی با مشکلاتی مانند استفاده ناکارآمد از حافظه و سختی در گسترش بر روی چندین دستگاه مواجه بودند. Otter به عنوان راهحلی برای این مشکلات طراحی شده، با ویژگیهایی نظیر الگوریتمهای بهتر برای حذف دادهها و مدیریت حافظه پیشرفته، تا عملکرد بهتری در محیطهای توزیعشده ارائه دهد.
🟣لینک مقاله:
https://golangweekly.com/link/171241/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
The Evolution of Caching Libraries in Go
🟢 خلاصه مقاله:
توسعهدهنده کتابخانه کش Otter، به بررسی تاریخچه کتابخانههای کش در زبان برنامهنویسی Go پرداخته است. او مشکلاتی که توسعهدهندگان در گذشته با آن روبرو بودهاند و دلایل به وجود آمدن Otter را شرح داده است. کتابخانههای کش قبلی با مشکلاتی مانند استفاده ناکارآمد از حافظه و سختی در گسترش بر روی چندین دستگاه مواجه بودند. Otter به عنوان راهحلی برای این مشکلات طراحی شده، با ویژگیهایی نظیر الگوریتمهای بهتر برای حذف دادهها و مدیریت حافظه پیشرفته، تا عملکرد بهتری در محیطهای توزیعشده ارائه دهد.
🟣لینک مقاله:
https://golangweekly.com/link/171241/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
maypok86.github.io
The Evolution of Caching Libraries in Go - Otter
❤3
🔵 عنوان مقاله
An Interactive Tour of Go 1.25
🟢 خلاصه مقاله:
نسخه نهایی Go 1.25 قرار است در ماه آگوست منتشر شود، و فرآیند توسعه آن طبق برنامه پیش میرود. نخستین نسخه آزمایشی، RC1، منتشر شده و نسخه دوم، RC2، انتظار میرود هفته آینده عرضه شود. یادداشتهای پیشنویس انتشار داده شده و شامل اطلاعات مفیدی درباره ویژگیها و بهبودهای جدید است. علاوه بر این، آنتون، شخصیت شناختهشده در جامعه Go، تورهای تعاملی خود را ارائه میدهد که در آنها میتوان به ویرایش و اجرای نمونههای کد مستقیماً از طریق مرورگر پرداخت.
🟣لینک مقاله:
https://golangweekly.com/link/171237/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
An Interactive Tour of Go 1.25
🟢 خلاصه مقاله:
نسخه نهایی Go 1.25 قرار است در ماه آگوست منتشر شود، و فرآیند توسعه آن طبق برنامه پیش میرود. نخستین نسخه آزمایشی، RC1، منتشر شده و نسخه دوم، RC2، انتظار میرود هفته آینده عرضه شود. یادداشتهای پیشنویس انتشار داده شده و شامل اطلاعات مفیدی درباره ویژگیها و بهبودهای جدید است. علاوه بر این، آنتون، شخصیت شناختهشده در جامعه Go، تورهای تعاملی خود را ارائه میدهد که در آنها میتوان به ویرایش و اجرای نمونههای کد مستقیماً از طریق مرورگر پرداخت.
🟣لینک مقاله:
https://golangweekly.com/link/171237/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
antonz.org
Go 1.25 interactive tour
Fake clock, new GC, flight recorder and more.
❤1👍1
🔴قابلیت New GC ویژگی های جدید گولنگ نسخه 1.25
در Go 1.25، یک جمعآورندهٔ زباله (GC) جدید به نام "Green Tea" معرفی شده که طراحی آن انقلابیست، مخصوص برنامههایی با تولید انبوه اشیاء کوچک و اجرا در سیستمهای چندهستهای مدرن:
🍵 چرا "Green Tea"؟
*درواقع GC فعلی Go مبتنی بر الگوریتم "tri-color parallel marking" است که اشیاء را جداگانه اسکن میکند؛ این باعث میشود حافظه بهشکل تصادفی خوانده شود و کش پر کاربرد (L1/L2) زیاد miss شود
* این Green Tea بهجای اسکن هر شیء، اسکن بلوکهای حافظه بزرگتر (span) را انجام میدهد تا locality حافظه حفظ شود، contention بین threadها کاهش یابد، و دسترسیها به حافظه سریعتر شود .
⚙️ نحوه عملکرد:
1. در spans (بلاک ۸ کیلوبایتی حافظه با اشیاء هماندازه)، دو نشانگر gray و black برای مدیریت حالت marking استفاده میشود. spans به صف عملگرها اضافه و بعد پردازش میشوند .
2. این ساختار باعث کاهش شدید فعالیت حافظه و افزایش همزمانی در محیطهای خیلی هستهای میشود .
📊 عملکرد و نتایج:
* در بنچمارکهای GC‑محور، کاهش ۱۰–۵۰٪ در مصرف CPU مربوط به GC مشاهده شده؛ مخصوصاً روی ماشینهای چندهستهای
* باعث کاهش بیش از ۵۰٪ در cache missها (L1/L2) شده
* البته در برخی بنچمارکها (مثلاً کامپایلر Go) ممکن است کمی افت عملکرد (\~۰.۵٪) دیده شود که در حال بررسی است
🧪 نحوه استفاده و فعالسازی:
* ویژگی Experimental است و میتوانید آن را بهصورت آزمایشی با:
فعال کنید .
* هدف این است که بتوان آن را در Go 1.25 بهعنوان یک گزینه فعالشدنی استفاده کرد، و ارزیابی واقعی روی پروژهها صورت گیرد
✍️ مثال فرضی استفاده:
فرض کنید برنامهای سرویسمحور دارید که بهطرز چشمگیری اشیاء کوچک ایجاد میکند (مثلاً در لایهی JSON/API). با فعال کردن Green Tea:
درواقعه * GC حافظه را بلوکی اسکن میکند، نه شیء به شیء.
* بار CPU مربوط به GC کاهش مییابد و کارایی کلی اپلیکیشن بهتر میشود.
بهعنوان مثال ساده:
وقتی quotaی garbage ایجاد میشود، جدیدترین GC بهجای اسکن ۱۰۰۰ شیء، spans را اسکن میکند و locality را حفظ میکند، بهینهتر عمل مینماید.
✅ جمعبندی:
* این Green Tea GC الگوریتمی توپولوژی-آگاه است که با توجه به ساختار حافظه سیستم، عملکرد marking را بهینه میکند.
* برای برنامههایی که اشیاء کوچک زیادی ایجاد میکنند و به performance حساس هستند، میتواند ۱۰–۵۰٪ کاهش در overhead GC فراهم کند.
* هنوز آزمایشیست؛ برای فعالسازی از
➖➖➖➖➖➖➖➖
👑 @gopher_academy
در Go 1.25، یک جمعآورندهٔ زباله (GC) جدید به نام "Green Tea" معرفی شده که طراحی آن انقلابیست، مخصوص برنامههایی با تولید انبوه اشیاء کوچک و اجرا در سیستمهای چندهستهای مدرن:
🍵 چرا "Green Tea"؟
*درواقع GC فعلی Go مبتنی بر الگوریتم "tri-color parallel marking" است که اشیاء را جداگانه اسکن میکند؛ این باعث میشود حافظه بهشکل تصادفی خوانده شود و کش پر کاربرد (L1/L2) زیاد miss شود
* این Green Tea بهجای اسکن هر شیء، اسکن بلوکهای حافظه بزرگتر (span) را انجام میدهد تا locality حافظه حفظ شود، contention بین threadها کاهش یابد، و دسترسیها به حافظه سریعتر شود .
⚙️ نحوه عملکرد:
1. در spans (بلاک ۸ کیلوبایتی حافظه با اشیاء هماندازه)، دو نشانگر gray و black برای مدیریت حالت marking استفاده میشود. spans به صف عملگرها اضافه و بعد پردازش میشوند .
2. این ساختار باعث کاهش شدید فعالیت حافظه و افزایش همزمانی در محیطهای خیلی هستهای میشود .
📊 عملکرد و نتایج:
* در بنچمارکهای GC‑محور، کاهش ۱۰–۵۰٪ در مصرف CPU مربوط به GC مشاهده شده؛ مخصوصاً روی ماشینهای چندهستهای
* باعث کاهش بیش از ۵۰٪ در cache missها (L1/L2) شده
* البته در برخی بنچمارکها (مثلاً کامپایلر Go) ممکن است کمی افت عملکرد (\~۰.۵٪) دیده شود که در حال بررسی است
🧪 نحوه استفاده و فعالسازی:
* ویژگی Experimental است و میتوانید آن را بهصورت آزمایشی با:
GOEXPERIMENT=greenteagc go test ./...
فعال کنید .
* هدف این است که بتوان آن را در Go 1.25 بهعنوان یک گزینه فعالشدنی استفاده کرد، و ارزیابی واقعی روی پروژهها صورت گیرد
✍️ مثال فرضی استفاده:
فرض کنید برنامهای سرویسمحور دارید که بهطرز چشمگیری اشیاء کوچک ایجاد میکند (مثلاً در لایهی JSON/API). با فعال کردن Green Tea:
درواقعه * GC حافظه را بلوکی اسکن میکند، نه شیء به شیء.
* بار CPU مربوط به GC کاهش مییابد و کارایی کلی اپلیکیشن بهتر میشود.
بهعنوان مثال ساده:
func handler(w http.ResponseWriter, r *http.Request) {
// بارگذاری و پردازش داده های کوچک متعدد
blobs := make([]*MyStruct, 1000)
for i := range blobs {
blobs[i] = &MyStruct{/*...*/}
}
// استفاده از blobs
}
وقتی quotaی garbage ایجاد میشود، جدیدترین GC بهجای اسکن ۱۰۰۰ شیء، spans را اسکن میکند و locality را حفظ میکند، بهینهتر عمل مینماید.
✅ جمعبندی:
* این Green Tea GC الگوریتمی توپولوژی-آگاه است که با توجه به ساختار حافظه سیستم، عملکرد marking را بهینه میکند.
* برای برنامههایی که اشیاء کوچک زیادی ایجاد میکنند و به performance حساس هستند، میتواند ۱۰–۵۰٪ کاهش در overhead GC فراهم کند.
* هنوز آزمایشیست؛ برای فعالسازی از
GOEXPERIMENT=greenteagc
استفاده کنید و توصیه میشود تستهای منتها اجرا دقیق انجام دهید.➖➖➖➖➖➖➖➖
👑 @gopher_academy
👍3❤1
Forwarded from DevOps Labdon
🔵 عنوان مقاله
How Google Cloud is securing open-source credentials at scale (3 minute read)
🟢 خلاصه مقاله:
Google Cloud ابزار اسکنی را توسعه داده است که به صورت خودکار اطلاعات کاربری فاششده را در آثار متنباز، از جمله بستهها و تصاویر داکر، شناسایی میکند. این امر به حفاظت از سوء استفاده و بهبود امنیت در زنجیره تامین نرمافزار کمک میکند. این سیستم امکان رفع سریع موارد فاششده دادههای کاربری را فراهم میآورد. به زودی، این ابزار توسعه یافته و شامل اعتبارات طرفهای ثالث و پوشش گستردهتری از پلتفرمهای متنباز خواهد شد. این پیشرفتها عناصر کلیدی هستند که به بهبود قابل توجهی در امنیت توزیع نرمافزار کمک میکنند و به مدیریت بهتر ریسکهای امنیتی مرتبط با نشت اطلاعات محرمانه و احراز هویت میپردازند.
🟣لینک مقاله:
https://cloud.google.com/blog/products/identity-security/securing-open-source-credentials-at-scale/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
How Google Cloud is securing open-source credentials at scale (3 minute read)
🟢 خلاصه مقاله:
Google Cloud ابزار اسکنی را توسعه داده است که به صورت خودکار اطلاعات کاربری فاششده را در آثار متنباز، از جمله بستهها و تصاویر داکر، شناسایی میکند. این امر به حفاظت از سوء استفاده و بهبود امنیت در زنجیره تامین نرمافزار کمک میکند. این سیستم امکان رفع سریع موارد فاششده دادههای کاربری را فراهم میآورد. به زودی، این ابزار توسعه یافته و شامل اعتبارات طرفهای ثالث و پوشش گستردهتری از پلتفرمهای متنباز خواهد شد. این پیشرفتها عناصر کلیدی هستند که به بهبود قابل توجهی در امنیت توزیع نرمافزار کمک میکنند و به مدیریت بهتر ریسکهای امنیتی مرتبط با نشت اطلاعات محرمانه و احراز هویت میپردازند.
🟣لینک مقاله:
https://cloud.google.com/blog/products/identity-security/securing-open-source-credentials-at-scale/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Google Cloud Blog
Securing open-source credentials at scale | Google Cloud Blog
We’ve developed a powerful tool to scan open-source package and image files by default for leaked Google Cloud credentials. Here’s how to use it.
🔵 عنوان مقاله
Cross-Compiling 10,000+ Go CLI Packages Statically
🟢 خلاصه مقاله:
مقاله به بررسی رویکرد جدید و غیرمعمول در ساخت ابزارهای خط فرمان Go به عنوان باینریهای استاتیک با استفاده از زنجیره ابزار Zig میپردازد. این روش با هدف سادهسازی استفاده از این ابزارها برای کاربرانی که زنجیره ابزار Go را نصب نکردهاند، انتخاب شدهاست. استفاده از باینریهای استاتیک باعث حذف نیاز به مدیریت وابستگیها و پیکربندیهای مرتبط با محیط Go میشود، و در نتیجه تجربه کاربری آسانتری را فراهم میآورد. این رویکرد نه تنها روند استقرار نرمافزار را سادهتر میکند بلکه دسترسی گستردهتری به ابزارهای CLI Go را برای تعداد بیشتری از کاربران فراهم میآورد.
🟣لینک مقاله:
https://golangweekly.com/link/171250/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Cross-Compiling 10,000+ Go CLI Packages Statically
🟢 خلاصه مقاله:
مقاله به بررسی رویکرد جدید و غیرمعمول در ساخت ابزارهای خط فرمان Go به عنوان باینریهای استاتیک با استفاده از زنجیره ابزار Zig میپردازد. این روش با هدف سادهسازی استفاده از این ابزارها برای کاربرانی که زنجیره ابزار Go را نصب نکردهاند، انتخاب شدهاست. استفاده از باینریهای استاتیک باعث حذف نیاز به مدیریت وابستگیها و پیکربندیهای مرتبط با محیط Go میشود، و در نتیجه تجربه کاربری آسانتری را فراهم میآورد. این رویکرد نه تنها روند استقرار نرمافزار را سادهتر میکند بلکه دسترسی گستردهتری به ابزارهای CLI Go را برای تعداد بیشتری از کاربران فراهم میآورد.
🟣لینک مقاله:
https://golangweekly.com/link/171250/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Package Forge
Cross-Compiling 10,000+ Go CLI Packages Statically
The Largest Collection of Pre-Compiled Go Static Binaries
❤2🔥1
Forwarded from AI Labdon
✍️Alireza KiakojouriAlireza Kiakojouri
بنیانگذار تلگرام: ChatGPT فکر نمیکند، فقط حرف میزند!/ پروژهی مخفی برادران دورف چیست؟
پاول دورف به نشریه فرانسوی «لو پوئن» گفت: «مدلهای هوش مصنوعی مثل ChatGPT فکر نمیکنند. فقط مقدار زیادی متن خواندهاند و پاسخی میدهند که به نظر درست میآید. اما واقعاً نمیفهمند و ما انسانها چون زبان پیچیده را نشانه هوش میدانیم، فریب میخوریم. مدلهای زبانی فقط حرف میزنند. اما این به معنای فهمیدن یا فکر کردن نیست.»
پاول میگوید برادرش (نیکلای دورف) اکنون روی ساخت مدلی کار میکند که واقعاً بتواند منطق را درک کند، تصمیم بگیرد و دنیای واقعی را بفهمد. او مدعی است این پروژه چیزی فراتر از مدلهای زبانی فعلی است.
در حالی که غولهایی مانند OpenAI، گوگل، متا و حتی چین و روسیه در حال رقابت برای ساخت نسل بعدی هوش مصنوعی (AGI) هستند، پروژه نیکلای دورف میتواند معادلات را تغییر دهد.
اگر پروژه نیکلای موفق شود، ما شاهد تولد هوش مصنوعیای خواهیم بود که فقط «هوشمندانه صحبت نمیکند»، بلکه واقعاً میفهمد، فکر میکند و تصمیم میگیرد.
بنیانگذار تلگرام: ChatGPT فکر نمیکند، فقط حرف میزند!/ پروژهی مخفی برادران دورف چیست؟
پاول دورف به نشریه فرانسوی «لو پوئن» گفت: «مدلهای هوش مصنوعی مثل ChatGPT فکر نمیکنند. فقط مقدار زیادی متن خواندهاند و پاسخی میدهند که به نظر درست میآید. اما واقعاً نمیفهمند و ما انسانها چون زبان پیچیده را نشانه هوش میدانیم، فریب میخوریم. مدلهای زبانی فقط حرف میزنند. اما این به معنای فهمیدن یا فکر کردن نیست.»
پاول میگوید برادرش (نیکلای دورف) اکنون روی ساخت مدلی کار میکند که واقعاً بتواند منطق را درک کند، تصمیم بگیرد و دنیای واقعی را بفهمد. او مدعی است این پروژه چیزی فراتر از مدلهای زبانی فعلی است.
در حالی که غولهایی مانند OpenAI، گوگل، متا و حتی چین و روسیه در حال رقابت برای ساخت نسل بعدی هوش مصنوعی (AGI) هستند، پروژه نیکلای دورف میتواند معادلات را تغییر دهد.
اگر پروژه نیکلای موفق شود، ما شاهد تولد هوش مصنوعیای خواهیم بود که فقط «هوشمندانه صحبت نمیکند»، بلکه واقعاً میفهمد، فکر میکند و تصمیم میگیرد.
❤2🔥2🕊2
🔵 عنوان مقاله
Depot Ships Gocache v2 for 4x Faster Go Builds
🟢 خلاصه مقاله:
مقالهی مذکور به بررسی تکنیکهای باندلینگ در محیطهای CI میپردازد که تعداد فراخوانیهای شبکهای را در پروژههای برنامهنویسی با زبان Go از هزاران به صدها مورد کاهش میدهد. این امر منجر به افزایش چشمگیر سرعت و کارایی فرآیندهای ساخت میشود و در نتیجه، زمان لازم برای تکمیل ساختها کاهش مییابد و خطاهای مرتبط با مشکلات شبکه کمتر میشود. این پیشرفت، سرعت و کارایی را در محیطهای توسعهی نرمافزاری که به CI بستگی دارند، بهبود میبخشد.
🟣لینک مقاله:
https://golangweekly.com/link/171251/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Depot Ships Gocache v2 for 4x Faster Go Builds
🟢 خلاصه مقاله:
مقالهی مذکور به بررسی تکنیکهای باندلینگ در محیطهای CI میپردازد که تعداد فراخوانیهای شبکهای را در پروژههای برنامهنویسی با زبان Go از هزاران به صدها مورد کاهش میدهد. این امر منجر به افزایش چشمگیر سرعت و کارایی فرآیندهای ساخت میشود و در نتیجه، زمان لازم برای تکمیل ساختها کاهش مییابد و خطاهای مرتبط با مشکلات شبکه کمتر میشود. این پیشرفت، سرعت و کارایی را در محیطهای توسعهی نرمافزاری که به CI بستگی دارند، بهبود میبخشد.
🟣لینک مقاله:
https://golangweekly.com/link/171251/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Depot
Now available: Gocache v2 for improved Golang build performance
We’re excited to announce Gocache v2, a major step forward in build caching for Go developers. Gocache v2 dramatically reduces build times by efficiently bundling and caching compile and test artifacts, and it’s now available in Depot Cache.
❤1
✍️Behnam Mohammadzadeh
اگر تو زبان Go عمیق شده باشین و سعی کرده باشین با نحوه عملکرد Scheduler آشنا بشین احتمالا Asynchronous Preemption به گوشتون خورده. تو این پست میخوام توضیح بدم که این اتفاق چطور میافته و نحوه عملکردش به چه شکله.
برای شروع شاید بد نباشه که بدونیم asynchronous preemption برای چی به وجود اومد و اصلا چه مشکلی رو حل میکنه؛ به همین منظور با یه مثال پیش میرم.
زمانی که GC میخواد اجرا بشه نیاز به (STW)Stop the World داره که تو این وضعیت باید همه گوروتین ها تو یه safe point متوقف بشن؛ کال شدن فانکشن یک safe point هست که گوروتین در این نقطه میتونه متوقف بشه تا GC کارش رو بدرستی انجام بده. ولی بعضی از گوروتین ها ممکنه موقع اجرا اصلا فانکشن کال نداشته باشن که به این حالت میگن tight loop.
تو این حالت گوروتین وقتی ۱۰ میلی ثانیه اجرا شد یه ترد به اسم sysmon که همیشه بصورت مستقل اجرا میشه میاد تشخیص میده که فلان گوروتین زیادی داره اجرا میشه و باید متوقف بشه تا نوبت به بقیه هم برسه و برای اینکه اون گوروتین رو متوقف کنه یه سیگنال SIGURG میفرسته.
از اونطرف یه گوروتین به اسم gSignal که هر ترد(M) یکی مخصوص خودش رو داره و میاد این سیگنالها رو دریافت و هندل میکنه .
وقتی gSignal میبینه سیگنال دریافتی از نوع SIGURG هست متوجه میشه که باید preemption اتفاق بیافته و میاد چک میکنه که آیا این اتفاق باید بیافته یا نه؟ (از لینک پایین هم میتونید این فانکشن رو ببینید)
https://lnkd.in/d-cad4-C
بعدش میاد چک کنه ببینه که اگه preempt کنیم مشکلی پیش میاد یا نه؟ پس این فانکشن رو کال میکنه
https://lnkd.in/d5HV8Sh9
دلیلش هم اینه که ممکنه این گوروتین در حال کال کردن بعضی از فانکشن های runtime باشه که نباید وسط اجرای اون فانکشن ها preemption اتفاق بیافته؛ و همچنین چک میکنه ببینه stack فضای کافی داره یا نه(چون مرحله بعد بهش نیاز داره).
حالا که به یه safe point رسیدیم میاد و کار خفن اصلی رو انجام میده.
❓همونطور که قبلا دیدیم tight loop هیچ فانکشن کالی نداره! پس چجوری باید گوروتین رو مجبور به اینکار کرد؟
✅ جواب، پوش کردن یک function call instruction به stack frame و تغییر PC هست!
این فانکشن این کار رو انجام میده:
https://lnkd.in/dcReVmHt
این فانکشن اول میاد برای یک instruction جدید داخل stack frame جا باز میکنه و بعد رجیسترهای RSP و RIP رو دستکاری میکنه تا PC به asyncPreempt تغییر کنه و بعد از اینکه اون اجرا شد کد قبلی بطور نرمال مثل گذشته به کارش ادامه بده.
لینک پست در ویرگول:
https://vrgl.ir/CLOKC
اگر تو زبان Go عمیق شده باشین و سعی کرده باشین با نحوه عملکرد Scheduler آشنا بشین احتمالا Asynchronous Preemption به گوشتون خورده. تو این پست میخوام توضیح بدم که این اتفاق چطور میافته و نحوه عملکردش به چه شکله.
برای شروع شاید بد نباشه که بدونیم asynchronous preemption برای چی به وجود اومد و اصلا چه مشکلی رو حل میکنه؛ به همین منظور با یه مثال پیش میرم.
زمانی که GC میخواد اجرا بشه نیاز به (STW)Stop the World داره که تو این وضعیت باید همه گوروتین ها تو یه safe point متوقف بشن؛ کال شدن فانکشن یک safe point هست که گوروتین در این نقطه میتونه متوقف بشه تا GC کارش رو بدرستی انجام بده. ولی بعضی از گوروتین ها ممکنه موقع اجرا اصلا فانکشن کال نداشته باشن که به این حالت میگن tight loop.
تو این حالت گوروتین وقتی ۱۰ میلی ثانیه اجرا شد یه ترد به اسم sysmon که همیشه بصورت مستقل اجرا میشه میاد تشخیص میده که فلان گوروتین زیادی داره اجرا میشه و باید متوقف بشه تا نوبت به بقیه هم برسه و برای اینکه اون گوروتین رو متوقف کنه یه سیگنال SIGURG میفرسته.
از اونطرف یه گوروتین به اسم gSignal که هر ترد(M) یکی مخصوص خودش رو داره و میاد این سیگنالها رو دریافت و هندل میکنه .
وقتی gSignal میبینه سیگنال دریافتی از نوع SIGURG هست متوجه میشه که باید preemption اتفاق بیافته و میاد چک میکنه که آیا این اتفاق باید بیافته یا نه؟ (از لینک پایین هم میتونید این فانکشن رو ببینید)
https://lnkd.in/d-cad4-C
بعدش میاد چک کنه ببینه که اگه preempt کنیم مشکلی پیش میاد یا نه؟ پس این فانکشن رو کال میکنه
https://lnkd.in/d5HV8Sh9
دلیلش هم اینه که ممکنه این گوروتین در حال کال کردن بعضی از فانکشن های runtime باشه که نباید وسط اجرای اون فانکشن ها preemption اتفاق بیافته؛ و همچنین چک میکنه ببینه stack فضای کافی داره یا نه(چون مرحله بعد بهش نیاز داره).
حالا که به یه safe point رسیدیم میاد و کار خفن اصلی رو انجام میده.
❓همونطور که قبلا دیدیم tight loop هیچ فانکشن کالی نداره! پس چجوری باید گوروتین رو مجبور به اینکار کرد؟
✅ جواب، پوش کردن یک function call instruction به stack frame و تغییر PC هست!
این فانکشن این کار رو انجام میده:
https://lnkd.in/dcReVmHt
این فانکشن اول میاد برای یک instruction جدید داخل stack frame جا باز میکنه و بعد رجیسترهای RSP و RIP رو دستکاری میکنه تا PC به asyncPreempt تغییر کنه و بعد از اینکه اون اجرا شد کد قبلی بطور نرمال مثل گذشته به کارش ادامه بده.
لینک پست در ویرگول:
https://vrgl.ir/CLOKC
lnkd.in
LinkedIn
This link will take you to a page that’s not on LinkedIn
❤3
اصطلاح STW یا Stop The World یکی از مفاهیم مهم در پیادهسازی Garbage Collector (GC) در زبانهایی مثل Go، Java و… هست. در ادامه با جزییات کامل بهش میپردازیم:
---
✅ تعریف STW (Stop The World)
> به زبان ساده: GC میگه «همه وایسید! من باید حافظه رو مرتب کنم».
---
📦 چرا GC نیاز به STW داره؟
Garbage Collector برای اینکه بتونه حافظهی بدون استفاده رو شناسایی و آزاد کنه، باید بدونه که:
* چه آبجکتهایی در حال حاضر در دسترس هستن (reachable)
* چه آبجکتهایی دیگه استفاده نمیشن (unreachable)
برای اینکه بتونه این بررسی رو دقیق انجام بده، باید:
* بررسی کنه که stack و heap در هر گوروتین در چه حالتی هستن
* مطمئن باشه که گوروتینها در نقطهای امن (safe point) قرار دارن، یعنی وسط نوشتن یا تغییر دادهای نیستن که باعث اشتباه در تحلیل بشه.
---
🧩 Safe Point یعنی چی؟
Safe point به جایی از اجرای کد گفته میشه که:
* وضعیت حافظه کاملاً قابل پیشبینیه
* گوروتین در حال اجرای عملیات بحرانی نیست
* GC میتونه بدون نگرانی از race condition، وضعیت حافظه رو بررسی و اصلاح کنه
مثلاً:
* موقع فراخوانی تابع
* موقع خروج از تابع
* قبل یا بعد از تخصیص حافظه
---
⚙️ فرآیند STW چطوری کار میکنه در Go؟
1. GC تصمیم میگیره که وقت پاکسازی حافظهست.
2. سیگنالی به تمام گوروتینها میده که باید به safe point برن.
3. وقتی همه گوروتینها به safe point رسیدن، برنامه وارد حالت STW میشه:
* هیچ کدی (حتی گوروتینها) اجرا نمیشن
4. GC با خیال راحت تحلیل حافظه (mark and sweep یا mark and compact) انجام میده.
5. بعد از اتمام کار GC، گوروتینها ادامهی اجرای خودشون رو از سر میگیرن.
---
🕐 STW در Go چقدر طول میکشه؟
در نسخههای جدید Go (مثلاً Go 1.18 به بعد):
* STW بسیار کوتاهه (در حد microsecond)
* Go از تکنیکهای پیشرفته مثل concurrent GC استفاده میکنه تا اکثر مراحل GC همزمان با اجرای برنامه انجام بشن
* فقط بخشهایی مثل شروع و پایان GC نیاز به STW دارن
---
🎯 چرا STW ممکنه مشکلساز بشه؟
اگر STW طولانی بشه:
* زمان پاسخدهی (latency) سیستم زیاد میشه
* در اپلیکیشنهای real-time یا interactive مثل گیم یا APIهای حساس، این تاخیر ممکنه قابلتحمل نباشه
* در برنامههای بزرگ با حافظه زیاد، ممکنه pauseها محسوس بشن
---
✅ تعریف STW (Stop The World)
STW
به وضعیتی در اجرای برنامه گفته میشه که اجرای تمام گوروتینها (یا تردها) متوقف میشن تا Garbage Collector بتونه کار خودش رو انجام بده.> به زبان ساده: GC میگه «همه وایسید! من باید حافظه رو مرتب کنم».
---
📦 چرا GC نیاز به STW داره؟
Garbage Collector برای اینکه بتونه حافظهی بدون استفاده رو شناسایی و آزاد کنه، باید بدونه که:
* چه آبجکتهایی در حال حاضر در دسترس هستن (reachable)
* چه آبجکتهایی دیگه استفاده نمیشن (unreachable)
برای اینکه بتونه این بررسی رو دقیق انجام بده، باید:
* بررسی کنه که stack و heap در هر گوروتین در چه حالتی هستن
* مطمئن باشه که گوروتینها در نقطهای امن (safe point) قرار دارن، یعنی وسط نوشتن یا تغییر دادهای نیستن که باعث اشتباه در تحلیل بشه.
---
🧩 Safe Point یعنی چی؟
Safe point به جایی از اجرای کد گفته میشه که:
* وضعیت حافظه کاملاً قابل پیشبینیه
* گوروتین در حال اجرای عملیات بحرانی نیست
* GC میتونه بدون نگرانی از race condition، وضعیت حافظه رو بررسی و اصلاح کنه
مثلاً:
* موقع فراخوانی تابع
* موقع خروج از تابع
* قبل یا بعد از تخصیص حافظه
---
⚙️ فرآیند STW چطوری کار میکنه در Go؟
1. GC تصمیم میگیره که وقت پاکسازی حافظهست.
2. سیگنالی به تمام گوروتینها میده که باید به safe point برن.
3. وقتی همه گوروتینها به safe point رسیدن، برنامه وارد حالت STW میشه:
* هیچ کدی (حتی گوروتینها) اجرا نمیشن
4. GC با خیال راحت تحلیل حافظه (mark and sweep یا mark and compact) انجام میده.
5. بعد از اتمام کار GC، گوروتینها ادامهی اجرای خودشون رو از سر میگیرن.
---
🕐 STW در Go چقدر طول میکشه؟
در نسخههای جدید Go (مثلاً Go 1.18 به بعد):
* STW بسیار کوتاهه (در حد microsecond)
* Go از تکنیکهای پیشرفته مثل concurrent GC استفاده میکنه تا اکثر مراحل GC همزمان با اجرای برنامه انجام بشن
* فقط بخشهایی مثل شروع و پایان GC نیاز به STW دارن
---
🎯 چرا STW ممکنه مشکلساز بشه؟
اگر STW طولانی بشه:
* زمان پاسخدهی (latency) سیستم زیاد میشه
* در اپلیکیشنهای real-time یا interactive مثل گیم یا APIهای حساس، این تاخیر ممکنه قابلتحمل نباشه
* در برنامههای بزرگ با حافظه زیاد، ممکنه pauseها محسوس بشن
❤3
برای دیدن نمودار و لاگهای واقعی اجرای GC در برنامه Go (و بررسی دقیق زمانهای STW)، میتونید از ابزارهای داخلی خود Go استفاده کنید..
🔧 مرحله 1: فعالسازی لاگ GC در Go
برای گرفتن لاگ دقیق GC، برنامهات رو با تنظیم متغیر
یا اگه داخل کد میخوای فعال کنی:
---
📜 نمونه لاگ واقعی GC در Go:
مثال خروجی لاگ با
🧩 تحلیل این لاگ:
|
|
|
|
|
|
|
|
---
📊 مرحله 2: گرفتن نمودار GC (با
1. اضافه کردن HTTP profiling:
2. اجرای برنامه و گرفتن پروفایل GC:
در ترمینال جدید:
یا برای لاگ GC دقیقتر:
سپس داخل مرورگر:
میتونی نمودارهای flamegraph، timeline و heap را ببینی.
---
✅ خلاصه
|
|
|
|
🔧 مرحله 1: فعالسازی لاگ GC در Go
برای گرفتن لاگ دقیق GC، برنامهات رو با تنظیم متغیر
GODEBUG
اجرا کن:GODEBUG=gctrace=1 ./your_program
یا اگه داخل کد میخوای فعال کنی:
import "runtime/debug"
func main() {
debug.SetGCPercent(100) // یا مقدار دلخواه
// بقیه کدها
}
---
📜 نمونه لاگ واقعی GC در Go:
مثال خروجی لاگ با
GODEBUG=gctrace=1
:gc 1 @0.004s 8%: 0.48+1.5+0.015 ms clock, 1.4+0.72/1.8/0+0.045 ms cpu, 4->4->2 MB, 5 MB goal, 4 P
🧩 تحلیل این لاگ:
|
gc 1
| شمارنده اجرای GC (این بار اولیه) ||
@0.004s
| زمان اجرای GC (۴ میلیثانیه بعد از شروع برنامه) ||
8%
| درصد زمانی که GC نسبت به زمان اجرای برنامه گرفته ||
0.48+1.5+0.015 ms clock
| ۳ فاز GC به ترتیب: STW شروع + Marking (concurrent) + STW پایان ||
1.4+0.72/1.8/0+0.045 ms cpu
| مصرف CPU در مراحل مختلف ||
4->4->2 MB
| حجم heap قبل، بعد از marking، بعد از sweep ||
5 MB goal
| هدف بعدی برای heap ||
4 P
| تعداد پردازندههای منطقی (GOMAXPROCS) |---
📊 مرحله 2: گرفتن نمودار GC (با
pprof
)1. اضافه کردن HTTP profiling:
import _ "net/http/pprof"
import "net/http"
go func() {
http.ListenAndServe("localhost:6060", nil)
}()
2. اجرای برنامه و گرفتن پروفایل GC:
در ترمینال جدید:
go tool pprof http://localhost:6060/debug/pprof/heap
یا برای لاگ GC دقیقتر:
go tool pprof -http=:8080 http://localhost:6060/debug/pprof/goroutine
سپس داخل مرورگر:
http://localhost:8080
میتونی نمودارهای flamegraph، timeline و heap را ببینی.
---
✅ خلاصه
|
GODEBUG=gctrace=1
| لاگ دقیق از اجرای GC و زمان STW ||
runtime/pprof
+ net/http/pprof
| ساختن پروفایلهای گرافیکی ||
go tool pprof
| بررسی گرافیکی یا CLI لاگها و ساخت flamegraph ||
debug.SetGCPercent
| تنظیم حساسیت GC |❤5🍾1