(#2) Как устроены крупные соц.сети изнутри. Часть 2 - разбор комментариев.

Nov 18, 2010 19:38

Это продолжение статьи http://spb-borodin.livejournal.com/596.html Ответы на многие поступившие вопросы. Рекомендую сначала прочитать первую часть.

Нужен ли мне это мастер-класс?

Есть два момента - сможете ли вы немедленно применить знания и будет ли он вам просто интересен.

Признаки, когда вы не сможете немедленно применить полученные знания, ( Read more... )

Leave a comment

l_o_n_g November 19 2010, 21:03:34 UTC
>Я знаю, что в php есть утечки памяти
Дима, будь добр, тки пальцем в то место, где течет? а то у нас как-то не текло (если только за собой не убирать созданные объекты), может мы что-то делали не так?

Reply

spb_borodin November 19 2010, 23:30:35 UTC
Текучесть есть из-за некоторых кривонаписанных PECL модулей. Про утечки в чистом php не знаю, не видел... Вернее, чистого php не видел ( ... )

Reply

pliskovs November 21 2010, 03:25:06 UTC
Вроде функция для работы с временем текла strtotime, simplexml грешил.
В корку тоже демоны падали периодически под freebsd, причин не разгребал в силу неимения сил и знаний.
Но это было года 3-4 назад. Кстати, вы же вроде пишете демонов, может на 5.3? как там работает сборщик мусора?

Reply

spb_borodin November 21 2010, 11:52:49 UTC
Демонов у нас пока нет, зато есть много крон скриптов. Они имеют защиту от утекания собственной памяти и перезапускаются, если что.

Reply

l_o_n_g November 22 2010, 00:03:18 UTC
strtotime у нас в демонах не течет.
simplexml это вообще странное создание, которое само по себе прожорливо (по крайне мере в тот единственный раз, когда я его использовал). благо потребности в xml сейчас не испытываю.
демоны, построенные на libevent, у нас прекрасно себя ведут - не падают и не текут (если разработчик не накосячит).
на проде - линух, но у одного из разработчиков - фряха, странностей так же не замечали.
сборщик мусора в 5.3 отлично работает (особенно в 5.3.3), но для демонов это не сильно актуально. если следить за ресурсами, освобождать их, когда не нужны - проблем не будет.

Reply

spb_borodin November 22 2010, 08:51:57 UTC
Надо сразу сделать демона перезапускаемым раз в N минут и контролем расходывания собственной памяти. И распределенным, т.е. чтобы одновременно несколько копий его работало. Тогда становится не важно - есть утечка или нет.

Reply

l_o_n_g November 22 2010, 10:07:02 UTC
интересно, чтобы ты ответил продавцу, если покупая новый компьютер в магазине, продавец посоветовал перегружать его каждые N минут, потому как у него память заканчивается, а если нужна непрерывная работа - купи себе 2 или три компа?

Reply

spb_borodin November 22 2010, 10:18:42 UTC
Ты думаешь я не хочу, чтобы оно не утекало? Я не советую строить задачи так, которые будут работать, только если память не будет утекать. Проще заранее предусмотреть худшее, что оно таки утекает.

Сейчас в Chrome под виндой злостно утекает память. Причем не пишется, что она занята процессом хрома. Винда сама куда-то девает ее, а спустя пару дней не закрытого хрома со специфической страницей - комп виснет, т.к. исрасходовал 10 гиг вирт памяти, при физических 4х. И ничего не сделать. Хром, винду обновлял, менять ОС или браузер - реально плохой совет. Я одновременно пользуюсь 3-мя браузерами.

Reply

l_o_n_g November 22 2010, 10:46:08 UTC
мы же говорим о приложении, которое сами разрабатываем? тогда в наших силах сделать так, чтобы не текло. а вот совет рестартить раз в n секунд - реально плохой совет. ибо сначала будет хватать 5 минут, потом 1 минуты, а потом придется рестартить после каждого запроса. при этом наверняка попутно решить проблемы с разогреванием кеша и прочими радостями работы в нештатном режиме.

Reply

spb_borodin November 22 2010, 11:05:36 UTC
Я не призываю уменьшать время менее 10 минут. Разумеется, в этом случае нужно пойти и подправить текущий говнокод. На практике такого не было. В обычной ситуации никаких утечек нет. Но при обновлении пхп может появится. И никто не пойдет разбираться с проблемой, если только оно не свалится. Заранее защитившись от утечки мы просто ничего не заметим и проект продолжит работу без падений. Без защиты от утечки - проект может упасть после обновления в момент, когда все как раз свалят с работы на выходные.

Reply

l_o_n_g November 22 2010, 13:04:09 UTC
вы же отслеживаете логи ошибок? чем утечка памяти отличается от прочих ошибок?
ну а смена версии PHP (да и не только PHP), которая происходит без предварительного тестирования, без обкатки на части продакшен-серверов - это возможность прострелить себе ногу. да и мониторинг расхода ресурсов - тоже никто не отменял. как только видим что память поползла после новой выкладки, мне кажется, надо начинать искать ошибку, а не бежать в магазин за новыми серверами?

Reply

spb_borodin November 22 2010, 13:13:17 UTC
Это все хорошо в теории. У нас десяток серверов только под крон задачи отведен (почти, что демоны). Память там не течет, т.к. все перезапускается, ошибок нет. Следить некогда. Но косвенный показатель есть - когда некоторые очереди медленнее разбираются.

Reply


Leave a comment

Up