The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Facebook представил механизм TMO, позволяющий экономить 20-32% памяти на серверах

21.06.2022 09:45

Инженеры из компании Facebook (запрещена в РФ) опубликовали отчёт о внедрении в прошлом году технологии TMO (Transparent Memory Offloading), позволяющей значительно экономить оперативную память на серверах за счёт вытеснения не требуемых для выполнения работы вторичных данных на более дешёвые накопители, такие как NVMe SSD-диски. По оценке Facebook, применение TMO позволяет экономить от 20 до 32% ОЗУ на каждом сервере. Решение рассчитано на применение в инфраструктурах, в которых приложения запускаются в изолированных контейнерах. Работающие на стороне ядра компоненты TMO уже включены в состав ядра Linux.

На стороне ядра Linux работа технологии обеспечивается подсистемой PSI (Pressure Stall Information), поставляемой начиная с выпуска 4.20. PSI уже применяется в различных обработчиках нехватки памяти и позволяет проанализировать информацию о времени ожидания получения различных ресурсов (CPU, память, ввод/вывод). При помощи PSI обработчики в пространстве пользователя могут более точно оценить уровень загруженности системы и характер замедления работы, что позволяет выявлять отклонения на самом раннем этапе, когда они ещё заметно не сказываются на производительности.

В пространстве пользователя работу TMO обеспечивает компонент Senpai, который через cgroup2 динамически корректирует ограничение памяти для контейнеров приложений на основании данных, полученных из PSI. Senpai анализирует признаки начала нехватки ресурсов через PSI, оценивает чувствительность приложений к замедлению доступа к памяти и пытается определить тот минимально необходимый контейнеру размер памяти, при котором требуемые для работы данные остаются в ОЗУ, а сопутствующие данные, осевшие в файловом кэше или напрямую не используемые в данный момент, вытесняются в раздел подкачки.

Таким образом, суть TMO в том, чтобы держать процессы на строгой диете с точки зрения потребления памяти, принудительно добиваясь переноса в раздел подкачки неиспользуемых страниц памяти, вытеснение которых заметно не влияет на производительность (например, страницы с кодом, используемым только при инициализации, и единично используемые данные в дисковом кэше). В отличие от вытеснения информации в раздел подкачки в ответ на нехватку памяти, в TMO данные вытесняются на основании упреждающего прогнозирования.

В качестве одного из критериев для вытеснения используется отсутствие обращения к странице памяти в течение 5 минут. Подобные страницы именуются холодными (cold memory page) и в среднем составляют около 35% памяти приложений (в зависимости от вида приложений наблюдается разброс от 19% до 65%). При вытеснении учитывается активность, связанная с анонимными страницами памяти (память, выделяемая приложением) и памятью, используемой при кэшировании файлов (выделяется ядром). В некоторых приложениях основное потребление связано с анонимной памятью, но в других большое значение имеет и файловый кэш. Для того, чтобы избежать дисбаланса при вытеснении памяти в кэш, в TMO применяется новый алгоритм подкачки, который вытесняет анонимные страницы и страницы, связанные с файловым кэшем, пропорционально.

Вытеснение редко используемых страниц в более медленную память не сказывается сильно на производительности, но позволяет значительно снизить расходы на оборудование. Данные вытесняются на SSD-накопители или в сжатую область подкачки в оперативной памяти. По стоимости хранения байта данных применение NVMe SSD до 10 раз дешевле использования сжатия в оперативной памяти.



  1. Главная ссылка к новости (https://engineering.fb.com/202...)
  2. OpenNews: Facebook открыл код статического анализатора Mariana Trench
  3. OpenNews: Facebook разработал открытую PCIe-карту с атомными часами
  4. OpenNews: Facebook открыл код Cinder, форка CPython, используемого в Instagram
  5. OpenNews: Facebook предложил новый механизм управления памятью slab для ядра Linux
  6. OpenNews: Facebook открыл код для обработки ситуации нехватки памяти в системе
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/57383-tmo
Ключевые слова: tmo, facebook, memory, psi, oom, offload
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (144) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 10:52, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +86 +/
    Сначала пишут жирный софт, а потом пытаются эффеективно свапиться. 2022.
     
     
  • 2.9, Аноним (9), 11:09, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    На чём основана твоя уверенность, что их задачи можно уместить в 640 КБ, и только лень не позволяет это сделать?
     
     
  • 3.19, Онанистмус (?), 11:38, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Facebook был написан на пхп а сейчас у них своя реализация пхп с типами и jit - hack lang. Hack это виртуальная машина, которая ест много памяти как и другие ВМ.
    Если бы они выбрали компилируемый язык типа golang то памяти требовалось бы в 10 раз меньше.
     
     
  • 4.26, Аноним (26), 11:50, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +19 +/
    Тут есть небольшая проблема, что если бы они писали на голанге или другом компилируемом языке. Большой компанией они бы никогда не стали. И их продукт никогда бы не взлетел. А так да ты прав.  
     
     
  • 5.37, Аноним (37), 12:36, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Если бы у твоей бабки был х, то она не была бы у.
     
  • 5.38, X86 (ok), 12:38, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не вижу причинной связи никакой. Наоборот, более эффективный софт выделял бы их в конкурентной борьбе.
     
     
  • 6.49, Аноним (26), 12:58, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Только в твоих влажных, пользователям пофиг на твой эффективный софт. Фейсбук бы просто ничего не выпустил, до сих пор бы занимались рефакторингом рефакторинга, а деньги бы у них закончились еще 16 лет назад. И все пользователи бы сидели в другой соцсети написаной на пыхе.  

    А как набрали пользователей можно и свой пых делать быстрый с блекджеком.  


    Давай тебе задача со звездочкой почему первая версия вконтакте написана на обычном пхп.  

     
     
  • 7.105, a_kusb (ok), 16:40, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Так когда набрали и нужно было переписывать на компилируемом.
    А ещё социальная сеть кажется мне простой программой.
     
     
  • 8.140, стоячок (?), 21:41, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    кажется... текст свёрнут, показать
     
  • 7.155, Первая буква (?), 14:24, 22/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А как набрали пользователей

    Не пользователей, а скот. Пользователи не позволяют к себе относится так, какую политику давно ведет конопатый жид.  

     
     
  • 8.156, a_kusb (ok), 18:37, 22/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А что там плохого в политике Не слежу за этим ... текст свёрнут, показать
     
  • 5.39, по (?), 12:39, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    динозавры тоже были большие и неэффективные, были да сплыли, просто окружение позволяло, вот и щас позволяет
     
  • 5.40, Аноним (40), 12:39, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Это правда - когда они начинали эффективный по ресурсам и при этом фичастый язык был один - С++. Хрен бы они что сделали на нём. Это теперь есть голанг. Но голанг тоже со сборщиком мусора и тоже неэффективный по ресурсам. Так что вариант один - раст.
     
     
  • 6.43, Аноним (43), 12:46, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > вариант один - раст

    Мозила попробовала - доломала FF окончательно с потерей всего рынка.

     
     
  • 7.97, Аноним (97), 15:52, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В Мозилле не в Расте дело, а в "эффективных менеджерах", которые распилили почти весь бюджет между собой и половину разрабов уволили. Есть ощущение, что Мозиллу ведут к планируемому банкротству и поглощению Гуглом или Майкрософтом, с выплатой "золотых парашютов" менеджменту. Ну как с Нокией было.
     
     
  • 8.133, Аноним (43), 20:15, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    У Нокии был фатальный недостаток она находилась не в Штатах ... текст свёрнут, показать
     
  • 6.71, Ананоним (?), 13:55, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    О как! А нам предлагали продукты, написанные на С++ и они даже работали? Хм. То ли нам такие продукты плохие продавали, то ли у них программисты негодные.
     
  • 6.118, anonymous (??), 18:42, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На самом деле уже в те времена был очень фичастый компилируемый язык со сборщиком мусора - Haskell. Единственный минус - порог вхождения высокий. Мало кто из пхпшников осилить способен.
     
  • 5.41, Анончик (?), 12:42, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Смелое утверждение. Поделитесь исходя из чего вы так решили?
     
     
  • 6.51, Аноним (26), 13:00, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Исходя из того что стоимость времени разработчика больше стоимости железа.  
     
     
  • 7.162, none7 (ok), 19:51, 23/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >Исходя из того что стоимость времени разработчика больше стоимости железа.  

    Даже если это железо приходится растаскивать на кучу ЦОД разбросанных по всему миру и построенных с нуля? Ой не факт. Просто Вы не учитываете, что у руководства может не стоять цели "потратить как можно меньше денег в долгосрочной перспективе". Обычно там цель в том, чтобы по быстрому состряпать макет и продать долю компании за миллиард. А дальше, да парись оно всё конём.

     
     
  • 8.165, Аноним (165), 15:44, 24/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так не бывает что у тебя ЦОДЫ и тысячи серверов по всему миру и один разработчик... текст свёрнут, показать
     
  • 5.42, Аноним (43), 12:44, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А гугл вообще ничего не писал, он только покупал готовое и продавал данные, результат - сам видишь.
     
     
  • 6.54, Аноним (26), 13:06, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Разрешите вам немножечко порвать шаблон. Спасибо за разрешение.

    Первая версия того что сейчас Google называлось BackRub это был научный проект Брина и Пейджа и написан оно было СЮРПРИЗ на Java и Python. А если бы они писали на С/С++ они бы тупо никогда не закончили проект и забили. И такой поиск бы сделал кто-то другой.  

    Совет прикладывайте к порванному шаблону подорожник, скоро заживет.  

     
     
  • 7.66, Медоед (?), 13:45, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Все верно, есть т.н. Lean методология, когда стадия стенда или прототипирования ставит в приоритет время и гибкость.

    Так же было с первыми шагами Твиттера, который был на Ruby on Rails.

    Но уже не первых стадиях зрелости, компании начинают вертикальную интеграцию (переписывают стабильные вещи на другом стэке), т.к. на масштабе это экономит большие деньги

    которые как раз можно потратить на новых сотрудников для новых продуктов и фич.

    FB явно перерос стадию прототипирования и при этом не перестал быть глючным говном, в котором ни комментарии свои не найти,

    ни даже ссылку на отдельный комментарий не дать (из приложения).

    Хорошо, что есть Reddit (с больным на голову медиа плеером, который у всех в мире виснет и лагает)

     
     
  • 8.93, funny.falcon (?), 15:33, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Reddit, написанный на python ... текст свёрнут, показать
     
     
  • 9.168, andrei (??), 12:13, 26/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Какие в ж пу фичи в Твиттере Увеличение сообщения больше 160 символов Доск... текст свёрнут, показать
     
  • 4.59, Онаним (?), 13:09, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    "Если бы они выбрали компилируемый язык"
    ... то настолько масштабного сервиса не было бы никогда. Был бы концепт за концептом.
    В этом всё веселье моднявых язычков. Реальные же серьёзные внедрения делаются на других.
     
     
  • 5.60, Онаним (?), 13:10, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ну а на сях фейсбук написать - не, можно наверное, но оно ж онлайновое, потом всё это поддерживать, отлаживать, деплоить... это просто ад трешовый.
     
  • 3.106, Аноним (106), 16:47, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я видел их код. За такой код надо запрещать работать в индустрии навсегда.
     
     
  • 4.166, Аноним (165), 15:45, 24/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё один любитель искусства ради искусства.  
     
  • 2.68, Аноним (68), 13:53, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • –6 +/
    >Сначала пишут жирный софт, а потом пытаются эффеективно свапиться. 2022.

    Да никто вам уже не будет байтики считать в 2022-м, ЗАБУДЬТЕ про это.

     
     
  • 3.85, _kp (ok), 14:54, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> байтики считать

    Удивитесь, но и сейчас считают, и ещё как.
    И востребованы весьма нестандартные способы сжатия.
    Есть низкоскоростные каналы связи, типа Lora, и радиоканал.
    А есть и гораздо более шустрые средства связи, но всё равно пропускная способность не резиновая.
    Да, это не совсем та область, о которой Вы подумали, но считают.

     
     
  • 4.102, Аноним (68), 16:18, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Причём здесь каналы связи? Я имел ввиду ОЗУ вычислительных устройств с полноценным ЦПУ и их софт.
     
     
  • 5.125, Аноним (125), 19:53, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А какой из стандартных алгоритмов сортировки выберете для строкового массива на пару Тб?
     
     
  • 6.138, Аноним (138), 21:05, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Выберу вот такой.

    Вон отсюда...

     
  • 6.142, _kp (ok), 22:36, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Стандартные маловероятно Была не очень давно задача не про сортировку, а поиск ... большой текст свёрнут, показать
     
     
  • 7.159, pavlinux (ok), 13:17, 23/06/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > применили алгоритм учитываюший характер данных,

    Открою секрет, у данных нет характера, это тупа куча байт.

    > построили модели  распределения данных,
    > модели сбоев, в алноритме поиска учитывается сколько операций может потребоваться до
    > длинной и коротким ветвям поиска, и вероятности попадания на короткие пути...

    Математики молодцы, заработали себе бабла из вакуума.

    1. Если в системe "работает" вероятностный выбор, значит данные х...во организованы изначально.
    2. Вероятностная выборка, в пределе, равна рандомному выбору, иначе данные х...во организованы изначально.
    3. Собственно цифры с 40 до 0.02 говорят о том, что данные х...во организованы изначально.

    )))

     
     
  • 8.161, _kp (ok), 19:15, 23/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен по пунктам 1 и 3 полностью, и по 2му на 30 Нельзя в готовом, и по ... текст свёрнут, показать
     
     
  • 9.164, pavlinux (ok), 14:29, 24/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Найти чупакабру на ноевом ковчеге - O N Найти чупакабру в зоопарке - O 1 ... текст свёрнут, показать
     

     ....большая нить свёрнута, показать (39)

  • 1.2, Аноним (2), 10:54, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А просто ссд или нвме диск в своп добавить не додумались.
     
     
  • 2.4, Alladin (?), 10:56, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    читай внимательно. они привязали данные ко времени, без этих ваших процентных содержаний озу.
     
     
  • 3.6, Аноним (26), 11:02, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А какой от этого толк что ты уберешь в своп что-то раньше по времени чем позже по процентам. У тебя же все равно будет неиспользованная оператива. Или ты пустую оперативу солить собрался? И оба подхода сойдутся когда опера и своп закончатся.  
     
     
  • 4.12, Alladin (?), 11:19, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    1. можно больше памяти пустить на кэши
    2. можно намного избирательнее относится к памяти так как всегда известно ее прошлое время обращение


    классический swap:
    1. начинаем выгружать при 60% озу
    2. выгружаем то что можно выгрузить не разбераясь в этом

     
     
  • 5.21, Аноним (26), 11:45, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Прям очень сильно натянутый сценарий Он наверняка отлично подходит для отчета д... большой текст свёрнут, показать
     
  • 2.10, Замир Закиев (?), 11:14, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Это своп другого уровня. Как я понял, гипервизор динамично управляет свопом/памятью в запущенных контейнерах (/виртуалках?). Это не совсем то, как если бы иметь своп исключительно на той или другой стороне. Как-то так.
     
     
  • 3.13, Alladin (?), 11:19, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    И это тоже
     

  • 1.3, Alladin (?), 10:56, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот что интересно.. привязать данные в озу к времени использования чтобы выгрузить неактуальные данные...
     
  • 1.5, Аноним (26), 10:57, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Они изобрели своп?
     
     
  • 2.8, Аноним (8), 11:07, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Они изобрели аккуратный своп, в отличие от классического, который выгружал всё подряд.

    Судя по описанию -- годно и нужно.

     
     
  • 3.22, Аноним (26), 11:46, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Судя по описанию это маркетинговый буллшит.  
     
     
  • 4.31, Аноним (31), 12:15, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    +
     
  • 2.56, arthi747 (ok), 13:07, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Когда прочитал думал они какой то супер пупер метод сжатия придумали. А они придумали ровно то же колво сметаны перекладывать в те же банки, но перекладывать "более сильнее".
     
  • 2.86, _kp (ok), 14:57, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Они улучшили своп
     

  • 1.7, Замир Закиев (?), 11:06, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +15 +/
    > компонент Senpai

    Надо взять на заметку! Вместо терминологии мастер/слейв можно употреблять сенсей/сенпай. Можно пойти еще дальше и употреблять рэй, ёй, каматэ, хачиме, ямэ и осс для обмена сообщений между клиент/сервером.

     
     
  • 2.16, Анонимкун (?), 11:31, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Сэмпай/кохай же.
     
     
  • 3.119, anonymous (??), 18:52, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Кохай - это "люби" по-украински?
     
  • 2.17, pda (ok), 11:32, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +8 +/
    OOMKiller переименовать в Яндере.
     
     
  • 3.28, Аноним (26), 11:54, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потом можно сразу переходить на персонажей аниме. Тогда OOMKiller это коро-сенсей.
     
  • 2.27, Аноним (27), 11:50, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    У щелочкоглазых очень развитая терминология в вопросах распределения ролей. Проблема в том, что надо быть реальным японистом, чтобы в этом всем не путаться. Вся команда разработки должна быть.
     
  • 2.70, ryoken (ok), 13:55, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А можно плз перевод терминов? С целью повышения уровня образованности.
     
     
  • 3.84, Замир Закиев (?), 14:54, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    это стандартные термины в каратэ (для общения, не для обозначения техник)

    рэй  - приветствие
    ёй - приготовиться
    осс - подтверждение (так точно, понял, готов)
    каматэ - принять боевую стойку
    хачиме - старт/начать
    ямэ - финиш/отбой

    сенсей - учитель
    сенпай - старший ученик
    кохай - младший ученик

     
     
  • 4.99, bq (?), 15:59, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    незнаю каратэ, начать разьве не hajime?
    в голодных сёстрах помойму было, hajimaru you!
     
  • 4.154, нгеро (?), 12:26, 22/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    ну так поди, сенпай он для кохая сенпай, а не для сенсея. Для сенсея он такой же кохай.
     
  • 3.87, _kp (ok), 15:01, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Там каламбур на тему одной игры.
    Замена политнекорректного OOMKiller на Яндере. Что тот же киллер, но с любовью.
     
  • 3.96, Kuromi (ok), 15:50, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Тут надо прояснить откуда берется семпай и кохай - у японцев в школах есть всякие клубы и прочие местные "комсомольские организации" в которых совместно участвуют ученики разных годов обучения, поэтому и появляется меду ними взаимодецствие с делением на "старший"\"младший". Потом такая модель отчасти тянется и более взрослую жизнь.
    У нас в Дикой такое ученики разных годов обычно никак не взаимодействуют.
     
     
  • 4.104, ryoken (ok), 16:40, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Насколько я помню из прочитанного - у японцев ообще сильно поделённое по возрасту\соц. положению общество, редко кто кому может напрямую обращаться.
     
     
  • 5.114, Kuromi (ok), 18:04, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Насколько я помню из прочитанного - у японцев ообще сильно поделённое по
    > возрасту\соц. положению общество, редко кто кому может напрямую обращаться.

    Ну это вообще характерно дял азиатов, хотя сейчас я так понимаю "не то что раньше". В Корее тоже самое.

     
  • 2.145, fuggy (ok), 00:31, 22/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Senpai, yamete kudasai, it doesn't fit. Out of memory.
     
  • 2.151, Serghei (?), 10:09, 22/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    барин/холоп
     
     
  • 3.167, Oxyd76 (?), 11:09, 25/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Никита Сергеич Михалков. Перелогиньтесь!
     
  • 2.163, Отражение луны (ok), 04:56, 24/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Уже. Долго же до вас тренды доходят.
     

  • 1.11, Бывалый смузихлёб (?), 11:18, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Заранее выкидывать из памяти. Ну-ну.
    На яблоке только недавно удалось отрубить нафиг тамошний своп
    Ведь валилось в него даже при половине или трети занятой ОЗУ и не высвобождалось даже когда ещё больше ОЗУ освобождалось
    Как ни странно, но красивой кнопки в настройках для этого не нашлось. И без консоли не обошлось. Даже с консолью - сам механизм решения проблемы не столь уж и простой

    Держу в курсе

     
     
  • 2.29, 67332 (?), 12:00, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А как не подскажите? MacOS убивает просто, 32GiB оператоса, i9 а тормозит как черте знает что -_-"
    А в компании выбор либо M$ либо MacOS из-за антивирусов и прочей фиготени.
     
     
  • 3.32, Ooiiii (?), 12:24, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > А в компании выбор либо M$ либо MacOS

    Лучше выбрать другую компанию

     
     
  • 4.110, Бывалый смузихлёб (?), 16:58, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >> А в компании выбор либо M$ либо MacOS

    Учитывая стоимость железок, бакс всё-таки корректней ставить яблоку - MacO$ или, просто O$ X

     
  • 3.98, Аноним (98), 15:56, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Бери мс - там и интерфейс человеческий и есть WSL что тот же линупc.
     
  • 3.108, Бывалый смузихлёб (?), 16:55, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Причин для тупни на яблоке может быть полно, но вот что по памяти Для начала от... большой текст свёрнут, показать
     

  • 1.14, suffix (ok), 11:23, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Любое вытеснение данных из оперативки в своп (что обычное, что умное от Фейсбук) это сигнал что необходимо немедленно или оптмиизировать приложения, или масштабировать (разносить) на большее кол-во серверов, или тупо добавлять оперативку. Использование свопа не есть нормальность, это лишь временный костыль позволяющий день простоять да ночь продержаться !
     
     
  • 2.23, Аноним (26), 11:47, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Походу хомки с 512 меговыми впсками радуются.  
     
  • 2.36, Аноним (36), 12:34, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Если в своп проваливается не tmpfs у тебя большая проблема. Даже если шоу со спецффектами пока почему-то не началось, то скоро это случится. Однако, в своп попадают и БЕСПОЛЕЗНЫЕ данные, а также УТЕКШАЯ память, использование свопа -- это единственный способ нормальной работы, просто кто-то уже это понял, а кто-то ещё не дорос и занимается самолюбованием по поводу "а я своп отключаю".
     
     
  • 3.44, suffix (ok), 12:50, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > просто кто-то уже это понял, а кто-то ещё не дорос и занимается самолюбованием по поводу "а я своп отключаю".

    Просто кто-то знает когда можно и нужно отключать своп а когда этого это делать не стоит. И когда лучше не экономить на железе, а когда пытаться за каждый рубль давиться. Разные задачи порождают разные решения. Кричать "своп нужен всегда" также глупо как кричать "а я своп отключаю".

     
  • 3.45, Аноним (26), 12:53, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Единственный способ временного решения проблем. Потечь конечно может и своп спасет. Но это лишь повод начинать искать пути решения. Добавить железок найти утечку или вовремя перезапускать потекший процесс.  Если ты постоянно работаешь со свопом у меня для тебя плохие новости.  
     
     
  • 4.53, Аноним (36), 13:02, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Иногда своп своим своим наличием увеличивает время беспроблемного аптайма до месяцев, а вот попытки его отключать приводят к тому, что памяти часто и внезапно начинает не хватать. Далеко не все операции требуют много памяти постоянно, временно можно поступиться перетеканием в своп огромной бесполезной кучи фоновых данных. Да и в целом, когда память используется под файловые кэши, это куда полезнее старых не востребованных данных оказывается. Есть ситуации, когда отключение свопа целесообразно (в основном критерий недопустимость любых задержек по этой причине), но на практике такие задачи ещё придётся поискать.
     
     
  • 5.81, Аноним (81), 14:45, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да, вот только частенько бывает обратное, свапование зачастую означает, что сист... большой текст свёрнут, показать
     
     
  • 6.82, Аноним (81), 14:47, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Свап был создан в те времена, когда ОЗУ объективно не хв... большой текст свёрнут, показать
     
     
  • 7.83, Аноним (81), 14:47, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >>> отключение свопа целесообразно (в основном критерий недопустимость любых задержек по этой
    >>> причине), но на практике такие задачи ещё придётся поискать.
    >> Да, вот только частенько бывает обратное, свапование зачастую означает, что система плотно
    >> и глубоко "задумывается", без возможности дать ей дополнительную задачу, чисто потому,
    >> что по какой-то интересной причине ОЗУ не забито, а система в
    >> свапе что-то ворочает со скоростью эстонской черепахи.
    >> Как бы ни был быстр ЖД, ОЗУ всё равно пока ещё быстрее,
    >> и зачастую свап ненужен, если ОЗУ физически хватает под задачи и
    >> даже вреден, для скорости работы.
    >был *худшим исходом, нежели...

     
  • 2.46, Аноним (46), 12:55, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Любое вытеснение данных из оперативки в своп (что обычное, что умное от Фейсбук) это сигнал что

    кнутом сечь нещадно нужно таких разработчиков.

     
  • 2.127, Аноним (127), 20:03, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Вы из тех, кто считает сервер с 256 ГБ RAM для раздачи торрентов минимумом?

    https://github.com/arvidn/libtorrent/issues/6667#issuecomment-1139232348

     
     
  • 3.135, suffix (ok), 20:28, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Мне кажется что Вы со своим вопросом промахнулись - он явно не ко мне.
     

  • 1.15, test1559 (?), 11:30, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    от 20 до 32%?
    zram и zswap в некоторых случаях экономит в 2-3 раза.
     
     
  • 2.24, Аноним (26), 11:48, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тсссс ты сейчас всё портишь.  
     
  • 2.35, Аноним (36), 12:29, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Zswap хорошая идея, но он заполняется целиком и памяти начинает сильно не хватать, программы падают. выполняешь swapoff/swapon и оказывается, что он был пустым, просто занятым. Этому багу уже лет 20.

    Zram просто толку никакого, сжатие там недостаточно эффективное, чтобы весь утёкший мусор пожать, да и не только он ведь туда стекает. Намного выгоднее чистая быстрая память и обычный своп.

     
     
  • 3.47, test1559 (?), 12:55, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В некоторых случаях, я же написал, понятное дело, что с какой-нибудь джавой zram не прокатит, но на отдельных виртуалках где много чего текстового в RAM заталкивается - очень даже неплохо все экономит. К примеру на виртуалках с документсерверами onlyoffice и collabora подрезал реальной ОЗУ в 2 раза после включения zswap и нормально работают.
     
  • 3.48, test1559 (?), 12:56, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    zram вернее
     
  • 3.52, Аноним (52), 13:01, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    в Zram сжатие эффективное, а вот скорость - нет
     
     
  • 4.55, Аноним (36), 13:06, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > в Zram сжатие эффективное, а вот скорость - нет

    Сжатие то эффективно, а вот размер окна -- нет. Это значит, что одинаковые данные за пределами окна будут сжаты несколько раз, отдельно.

     
  • 3.91, Аноним (91), 15:29, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >и оказывается, что он был пустым, просто занятым. Этому багу уже лет 20.

    man для кого писан?
    Опцию монтирования discard в Zswap докинь, Шклифасофский.

     
     
  • 4.94, Аноним (36), 15:37, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >No results found for zswap discard.

    но не уверен, как это должно помочь, никогда не слышал о таком.

     
     
  • 5.143, Аноним (143), 23:13, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Именно тем и поможет - без опции discard не происходит высвобождение страниц zswap, они продолжают висеть занятыми и после протухания.
     
  • 3.128, Аноним (127), 20:05, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Быть может, у вас включён и zram, и zswap одновременно? Я встречал описываемый вами баг именно в таком сценарии.
     

  • 1.30, Аноним (30), 12:03, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Больше всего хочется: Гугл значительно оптимизировал и сократил потребление ОЗУ браузера Chrome. А встроенный MPV позволит просматривать видео даже на некрожелезе. Установочный файл весит всего 10 Мб.
     
     
  • 2.33, Аноним (33), 12:24, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не дождёшься
     
  • 2.80, Аристарх (??), 14:43, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Там не гугл виноват. Просто почитай сам стандарт HTML - охренеешь, сколько всего вычурного и костылеподобного надо поддерживать! А ещё ведь есть CSS, JS, мультимедия, отладочные средства... не удивлён, что chrome.dll занимает 170МБ! Хотя многовато для софта, да.

    Мы бы давно перешли бы к "тонкому вебу", если б г***но HTML заменили бы на адекватный стандарт паблишинга.

     
     
  • 3.103, Аноним (-), 16:38, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    XHTML?
     
     
  • 4.132, Аноним (43), 20:13, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    PDF. Он изначально был кандидатом для веб, но кое-кто подсуетился, и теперь имеем дерьмохтмл.
     
  • 2.139, Аноним (139), 21:28, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Установочный файл весит всего 10 Мб.

    Есть такие, из разряда веб-инсталляторов. Качаешь такой на пару мегабайт, а тот потом в процессе установки еще половину интернета выкачает.

    Не фанат я такого рода вещей.

     

  • 1.34, Аноним (46), 12:26, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А может ли эта технлогия использоваться в обычном свопе на HDD, чтобы trashingа и 12309 не было?
     
     
  • 2.126, Аноним (127), 20:00, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Для этого разработчик Google уже несколько лет пытается включить патч в стандартное ядро Linux: https://lore.kernel.org/lkml/20220614071650.206064-1-yuzhao@google.com/#r

    Подобная технология уже около 10 лет работает на Chrome OS и несколько лет на Android. Вот здесь я писал эффект от альтернативного патча, который делает почти то же самое, там же есть видео: https://notes.valdikss.org.ru/linux-for-old-pc-from-2007/

     

  • 1.50, Без аргументов (?), 12:58, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Понаделали своих реактора и прочих ректал нативов, а теперь мучаются.
     
  • 1.57, VladSh (?), 13:07, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Ничё так идея - гробить ресурс SSD ради экономии оперативки...
     
     
  • 2.62, Аноним (62), 13:14, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не гробить, а использовать. Если так получается выгоднее, то почему нет?
     
     
  • 3.109, VladSh (?), 16:57, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Считать надо. Но я сильно сомневаюсь. Во-1, - оператива, считай, вечная - капитальные затраты единожды и всё, а SSD, даже самый лучший, менять надо, тем более при таком сценарии использования. Во-2, народ наоборот часть данных на RAM-диски перенести пытается далеко не зря.
     
     
  • 4.134, ыы (?), 20:20, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Посчитайте пожалуйста. А то у нас у всех лапки....
     
  • 2.67, Аноним (67), 13:50, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Как там, в 2010-х?
     
  • 2.72, Аноним (68), 14:02, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Они-то себе могут и MLC позволить. А вот для простых линуксоидов(-гентоводов) они исчезли из продажи.
     
     
  • 3.160, InuYasha (??), 17:45, 23/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    даже мыльце от такого не спасёт в долгосрочной перспективе, и даже сальце (SLC).
     

  • 1.58, Аноним (62), 13:09, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Не понимаю, зачем это всё. Разве своп не так же работал? Это позор конечно. Но если своп работал не так, значит надо было его доработать, а не городить велосипеды.
     
     
  • 2.130, Аноним (127), 20:10, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Текущая версия swap в линуксе работает, прямо скажем, неоптимально Там использу... большой текст свёрнут, показать
     

  • 1.61, Онаним (?), 13:12, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А потом приложение внезапно по какому-то редкому запросу решает сходить в "холодную" память, и ВЕСЕЛУХА.
    Не, в масштабах фейсбука всё понятно, там 99% хипа висят сутки мёртвым грузом в качестве кеша для очень редких обращений. Но за пределами применимость так себе. Это как RocksDB - на определённых применениях оно более-менее годно, но за их пределами - вообще неприменимо.
     
  • 1.63, Аноним (63), 13:31, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > на более дешёвые накопители, такие как NVMe SSD-диски

    Чет как-то не очень понял. Памать конечно дороже денег/мегабайт, но она хотябы не рассыпается от использования за год как вышеуказанные "дешевые" накопители. Как-то не очень экономично звучит.

     
  • 1.64, Аноним (64), 13:35, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > через cgroup2 динамически корректирует ограничение памяти

    Там разве не жёсткое ограничение? Приложение же упадёт если сделать ограничение на память меньше чем ему нужно.

     
  • 1.65, lockywolf (ok), 13:37, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Зачем _вообще_ эвиктить исполняемые страницы? 90% памяти -- это же ресурсы, а не код.
     
     
  • 2.101, Аноним (101), 16:01, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    100500 подгруженых либ, в которых реально используется 0.1% кода не согласны. И код инициализвции тоже.
     

  • 1.77, Аноним (81), 14:33, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    "позволяющей значительно экономить оперативную память на серверах за счёт вытеснения не требуемых для выполнения работы вторичных данных на более дешёвые накопители, такие как NVMe SSD-диски"

    Эээ... WUT?!
    С каких это пор с ограниченным циклом перезаписи SSD стали дешевле "вечной" ОЗУ?!

    Я где-то проспал техническую революцию в вопросе "вечной" жизни ssd?

     
     
  • 2.95, Роман (??), 15:44, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    интересный вопрос - вы считаете их почему-то должна заботить "вечная" жизнь дисков, они как-то прикипели к ним душой? или их больше должно заботить залезть в нарастающий рынок VR на 100500 миллиардов и надо успеть сформировать его на своих правилах, а там уже на сдачу поменять просто все диски (ну чего бы нет, от доброты душевной) или вообще на Optane переехать (может у них уже Optane местами конечно)
     
  • 2.107, Аноним (107), 16:54, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >С каких это пор с ограниченным циклом перезаписи SSD стали дешевле "вечной" ОЗУ?!
    >Я где-то проспал техническую революцию в вопросе "вечной" жизни ssd?

    У тебя просто пробелы в экономике. Сравни стоимость гигабайта SSD и гигабайта серверной RAM ECC.
    Если Facebook решил для себя, что регулярно менять сдохшие SSD дешевле, чем докупать дополнительной RAM, значит так оно и есть - корпорации априори считают деньги.
    "Если ты не видишь суслика, это не значит, что его нет"

     
     
  • 3.121, Аноним (43), 19:01, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > регулярно менять сдохшие SSD дешевле

    регулярно терять сдохшие данные хомячков - дешевле

     
     
  • 4.122, Аноним (43), 19:02, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    P.S. сначала продадут, потом потеряют, чтобы на ковре в Конгрессе не сильно пинали.
     
  • 4.123, Аноним (107), 19:13, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Именно так!
    В шкале приоритетов на первом месте прибыль, а хомячки - на последнем
     

  • 1.112, КО (?), 17:35, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    То есть теперь накопители будут изнашиваться ещё быстрее?
    А смысл тогда в увеличении производительности засчет доп. затрат?
     
     
  • 2.113, Аноним (107), 17:52, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Знаешь способ увеличения производительности без доп. затрат? Патентуй скорее.
     
     
  • 3.116, Попандопала (?), 18:28, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Уже же все запатентовали. Мульен терабайтный свап файл выгоднее, чем столько рамы покупать. Не удивлюсь если сейчас проблемы с производством, доставкой колбасы.D Говорили же инфу у нас локализуйте, так нет же...XD
     

  • 1.124, Аноним (124), 19:28, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > экономить оперативную память на серверах за счёт вытеснения не требуемых для выполнения работы вторичных данных

    Мы настолько уже привыкли к дерьмовой архитектуре ПО, что даже не замечаем ужас тех проблем, которые устраняем. Вдумайтесь: оптимизация затрат памяти за счёт некоего исключения НЕНУЖНЫХ данных! Как они там оказались? Зачем ненужные неиспользуемые данные находятся в оперативной памяти? Что за разработчики создают ПО, которое создаёт неиспользуемые данные на определённом интервале работы ПО?

    Это катастрофа.

     
     
  • 2.129, ыы (?), 20:05, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >Как они там оказались?

    Они там остались от предыдущей операции, в которой они были нужны.

    >Зачем ненужные неиспользуемые данные находятся в оперативной памяти?

    Они ждут отработки стандартного механизма вытеснения данных на уровне ОС. Но к сожалению ОС - ничего не знает о внутренней логике приложения, и весьма вероятно, что алгоритм реализованный на уровне ОС вытеснит в первую очередь "не те данные" которые мог бы вытеснить. Предложенный механизм действует более эффективно.
    Возможно в следующей версии ядра вы получите его по умолчанию...

    >Что за разработчики создают ПО, которое создаёт неиспользуемые данные на определённом интервале работы ПО?

    Вам походу до них еще учится, учится и учится... :)

     
  • 2.131, Аноним (127), 20:12, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Только не читайте про стандартный аллокатор malloc в glibc: сильно будете удивлены, что он почти не отдаёт данные при выполнении операции free().
     
     
  • 3.137, YetAnotherOnanym (ok), 20:55, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Надо же... А я когда-то написал демона на сях, у которого в цикле было malloc в начале и free в конце, так он месяцами крутился и не тёк. А должен был бы течь, если free не освобождает.
     
     
  • 4.141, Аноним (127), 22:16, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Современные версии аллокатора в glibc не отдают память в ОС, выделенную на хипе, если её нельзя уменьшить через sbrk, а аллокации через новые регионы требуют выделения сразу большого количества памяти за раз (от 16 МБ, если не ошибаюсь).
    Баг от 2006 года: https://sourceware.org/bugzilla/show_bug.cgi?id=2531
    https://stackoverflow.com/a/48652734
     
     
  • 5.149, YetAnotherOnanym (ok), 07:57, 22/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Гы... Теперь олдфаги могут кряхтеть, что "раньше и malloc/free нормально работали".
     
  • 2.136, YetAnotherOnanym (ok), 20:50, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Щас прибежит один из Анонимов и будет с пеной у рта доказывать, что только так и можно написать успешный проект.
     

  • 1.144, Аноним (144), 23:40, 21/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Прочитал комментарии и не понял, есть ли какие-то претензии к продукту, кроме того, что его написал фейсбук?
     
     
  • 2.158, Аноним (158), 00:20, 23/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Технологии свопа уже лет 30 если не больше, и во всех осях она есть по дефолту, на кой нужна подделка от мордокниги?
     

  • 1.148, Аноним (148), 06:51, 22/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    на что только не пойдет мордокнига для своих php извращений
     
  • 1.157, Аноним (158), 00:19, 23/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Переизобрели своп, мое почтение всем велосипедостроителям мира
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру