The OpenNET Project / Index page

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



"Facebook представил механизм TMO, позволяющий экономить 20-32% памяти на серверах"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

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

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=57383

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 21-Июн-22, 10:52   +86 +/
Сначала пишут жирный софт, а потом пытаются эффеективно свапиться. 2022.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #68

2. Сообщение от Аноним (2), 21-Июн-22, 10:54   –1 +/
А просто ссд или нвме диск в своп добавить не додумались.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #10

3. Сообщение от Alladin (?), 21-Июн-22, 10:56   +/
Вот что интересно.. привязать данные в озу к времени использования чтобы выгрузить неактуальные данные...
Ответить | Правка | Наверх | Cообщить модератору

4. Сообщение от Alladin (?), 21-Июн-22, 10:56   +3 +/
читай внимательно. они привязали данные ко времени, без этих ваших процентных содержаний озу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #6

5. Сообщение от Аноним (26), 21-Июн-22, 10:57   +1 +/
Они изобрели своп?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #56, #86

6. Сообщение от Аноним (26), 21-Июн-22, 11:02   +/
А какой от этого толк что ты уберешь в своп что-то раньше по времени чем позже по процентам. У тебя же все равно будет неиспользованная оператива. Или ты пустую оперативу солить собрался? И оба подхода сойдутся когда опера и своп закончатся.  
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #12

7. Сообщение от Замир Закиев (?), 21-Июн-22, 11:06   +15 +/
> компонент Senpai

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16, #17, #27, #70, #145, #151, #163

8. Сообщение от Аноним (8), 21-Июн-22, 11:07   +8 +/
Они изобрели аккуратный своп, в отличие от классического, который выгружал всё подряд.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #22

9. Сообщение от Аноним (9), 21-Июн-22, 11:09   +2 +/
На чём основана твоя уверенность, что их задачи можно уместить в 640 КБ, и только лень не позволяет это сделать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #19, #106

10. Сообщение от Замир Закиев (?), 21-Июн-22, 11:14   +/
Это своп другого уровня. Как я понял, гипервизор динамично управляет свопом/памятью в запущенных контейнерах (/виртуалках?). Это не совсем то, как если бы иметь своп исключительно на той или другой стороне. Как-то так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #13

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

Держу в курсе

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29

12. Сообщение от Alladin (?), 21-Июн-22, 11:19   +/
1. можно больше памяти пустить на кэши
2. можно намного избирательнее относится к памяти так как всегда известно ее прошлое время обращение


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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #21

13. Сообщение от Alladin (?), 21-Июн-22, 11:19   +/
И это тоже
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

14. Сообщение от suffix (ok), 21-Июн-22, 11:23   +5 +/
Любое вытеснение данных из оперативки в своп (что обычное, что умное от Фейсбук) это сигнал что необходимо немедленно или оптмиизировать приложения, или масштабировать (разносить) на большее кол-во серверов, или тупо добавлять оперативку. Использование свопа не есть нормальность, это лишь временный костыль позволяющий день простоять да ночь продержаться !
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23, #36, #46, #127

15. Сообщение от test1559 (?), 21-Июн-22, 11:30   +1 +/
от 20 до 32%?
zram и zswap в некоторых случаях экономит в 2-3 раза.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24, #35

16. Сообщение от Анонимкун (?), 21-Июн-22, 11:31   +12 +/
Сэмпай/кохай же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #119

17. Сообщение от pda (ok), 21-Июн-22, 11:32   +8 +/
OOMKiller переименовать в Яндере.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #28

19. Сообщение от Онанистмус (?), 21-Июн-22, 11:38   +8 +/
Facebook был написан на пхп а сейчас у них своя реализация пхп с типами и jit - hack lang. Hack это виртуальная машина, которая ест много памяти как и другие ВМ.
Если бы они выбрали компилируемый язык типа golang то памяти требовалось бы в 10 раз меньше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #26, #59

21. Сообщение от Аноним (26), 21-Июн-22, 11:45   +4 +/
Прям очень сильно натянутый сценарий. Он наверняка отлично подходит для отчета для менеджера смотрите вот эта кривая ниже проходит. Мы теперь делаем ту же работу, а сумма свободной оперы у нас больше! Это же положительный рост!  

Если тебе так нужен кеш и ты к нему так часто обращаешься он и при старой системе свопа будет в опере и вытеснит всё ненужное в своп. Даже если в обычной системе есть временной лаг между переполнением оперы и началом свопа он не выглядит чем то заградительным.

Я  бы даже поверил что это полезно для десктопа, например мак принудительно свопит даже если у него полностью пустая система. По своему фирменному алгоритму. Тут можно поверить что ты запустил тяжелое приложение и чтобы оно быстро стартануло, надо быстро все в оперу закинуть. А если она пустая то вообще норм. Но на сервере такой сценарий очень натянут.  

Я бы может сабжу и нашел сценарий на сервере, но только в случае ручного управление, какому приложению можно всегда быть в своп, какому никогда в своп не попадать. Но сабж такой функционал не предполагает.  

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

22. Сообщение от Аноним (26), 21-Июн-22, 11:46   +/
Судя по описанию это маркетинговый буллшит.  
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #31

23. Сообщение от Аноним (26), 21-Июн-22, 11:47   +2 +/
Походу хомки с 512 меговыми впсками радуются.  
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

24. Сообщение от Аноним (26), 21-Июн-22, 11:48   +1 +/
Тсссс ты сейчас всё портишь.  
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

26. Сообщение от Аноним (26), 21-Июн-22, 11:50   +19 +/
Тут есть небольшая проблема, что если бы они писали на голанге или другом компилируемом языке. Большой компанией они бы никогда не стали. И их продукт никогда бы не взлетел. А так да ты прав.  
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #37, #38, #39, #40, #41, #42

27. Сообщение от Аноним (27), 21-Июн-22, 11:50   +3 +/
У щелочкоглазых очень развитая терминология в вопросах распределения ролей. Проблема в том, что надо быть реальным японистом, чтобы в этом всем не путаться. Вся команда разработки должна быть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

28. Сообщение от Аноним (26), 21-Июн-22, 11:54   +1 +/
Потом можно сразу переходить на персонажей аниме. Тогда OOMKiller это коро-сенсей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

29. Сообщение от 67332 (?), 21-Июн-22, 12:00   +/
А как не подскажите? MacOS убивает просто, 32GiB оператоса, i9 а тормозит как черте знает что -_-"
А в компании выбор либо M$ либо MacOS из-за антивирусов и прочей фиготени.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #32, #98, #108

30. Сообщение от Аноним (30), 21-Июн-22, 12:03   +1 +/
Больше всего хочется: Гугл значительно оптимизировал и сократил потребление ОЗУ браузера Chrome. А встроенный MPV позволит просматривать видео даже на некрожелезе. Установочный файл весит всего 10 Мб.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #33, #80, #139

31. Сообщение от Анонимemail (31), 21-Июн-22, 12:15   +/
+
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

32. Сообщение от Ooiiii (?), 21-Июн-22, 12:24   +7 +/
> А в компании выбор либо M$ либо MacOS

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #110

33. Сообщение от Аноним (33), 21-Июн-22, 12:24   +/
Не дождёшься
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

34. Сообщение от Аноним (46), 21-Июн-22, 12:26   +/
А может ли эта технлогия использоваться в обычном свопе на HDD, чтобы trashingа и 12309 не было?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #126

35. Сообщение от Аноним (36), 21-Июн-22, 12:29   +/
Zswap хорошая идея, но он заполняется целиком и памяти начинает сильно не хватать, программы падают. выполняешь swapoff/swapon и оказывается, что он был пустым, просто занятым. Этому багу уже лет 20.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #47, #48, #52, #91, #128

36. Сообщение от Аноним (36), 21-Июн-22, 12:34   +2 +/
Если в своп проваливается не tmpfs у тебя большая проблема. Даже если шоу со спецффектами пока почему-то не началось, то скоро это случится. Однако, в своп попадают и БЕСПОЛЕЗНЫЕ данные, а также УТЕКШАЯ память, использование свопа -- это единственный способ нормальной работы, просто кто-то уже это понял, а кто-то ещё не дорос и занимается самолюбованием по поводу "а я своп отключаю".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #44, #45

37. Сообщение от Аноним (37), 21-Июн-22, 12:36   –2 +/
Если бы у твоей бабки был х, то она не была бы у.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

38. Сообщение от X86 (ok), 21-Июн-22, 12:38   –1 +/
Не вижу причинной связи никакой. Наоборот, более эффективный софт выделял бы их в конкурентной борьбе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #49

39. Сообщение от по (?), 21-Июн-22, 12:39   +4 +/
динозавры тоже были большие и неэффективные, были да сплыли, просто окружение позволяло, вот и щас позволяет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

40. Сообщение от Аноним (40), 21-Июн-22, 12:39   –6 +/
Это правда - когда они начинали эффективный по ресурсам и при этом фичастый язык был один - С++. Хрен бы они что сделали на нём. Это теперь есть голанг. Но голанг тоже со сборщиком мусора и тоже неэффективный по ресурсам. Так что вариант один - раст.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #43, #71, #118

41. Сообщение от Анончик (?), 21-Июн-22, 12:42   +2 +/
Смелое утверждение. Поделитесь исходя из чего вы так решили?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #51

42. Сообщение от Аноним (43), 21-Июн-22, 12:44   –2 +/
А гугл вообще ничего не писал, он только покупал готовое и продавал данные, результат - сам видишь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #54

43. Сообщение от Аноним (43), 21-Июн-22, 12:46   +2 +/
> вариант один - раст

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #97

44. Сообщение от suffix (ok), 21-Июн-22, 12:50   –1 +/
> просто кто-то уже это понял, а кто-то ещё не дорос и занимается самолюбованием по поводу "а я своп отключаю".

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

45. Сообщение от Аноним (26), 21-Июн-22, 12:53   +/
Единственный способ временного решения проблем. Потечь конечно может и своп спасет. Но это лишь повод начинать искать пути решения. Добавить железок найти утечку или вовремя перезапускать потекший процесс.  Если ты постоянно работаешь со свопом у меня для тебя плохие новости.  
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #53

46. Сообщение от Аноним (46), 21-Июн-22, 12:55   +/
> Любое вытеснение данных из оперативки в своп (что обычное, что умное от Фейсбук) это сигнал что

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

47. Сообщение от test1559 (?), 21-Июн-22, 12:55   +/
В некоторых случаях, я же написал, понятное дело, что с какой-нибудь джавой zram не прокатит, но на отдельных виртуалках где много чего текстового в RAM заталкивается - очень даже неплохо все экономит. К примеру на виртуалках с документсерверами onlyoffice и collabora подрезал реальной ОЗУ в 2 раза после включения zswap и нормально работают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

48. Сообщение от test1559 (?), 21-Июн-22, 12:56   +/
zram вернее
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

49. Сообщение от Аноним (26), 21-Июн-22, 12:58   +10 +/
Только в твоих влажных, пользователям пофиг на твой эффективный софт. Фейсбук бы просто ничего не выпустил, до сих пор бы занимались рефакторингом рефакторинга, а деньги бы у них закончились еще 16 лет назад. И все пользователи бы сидели в другой соцсети написаной на пыхе.  

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


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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #105, #155

50. Сообщение от Без аргументов (?), 21-Июн-22, 12:58   –1 +/
Понаделали своих реактора и прочих ректал нативов, а теперь мучаются.
Ответить | Правка | Наверх | Cообщить модератору

51. Сообщение от Аноним (26), 21-Июн-22, 13:00   +/
Исходя из того что стоимость времени разработчика больше стоимости железа.  
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #162

52. Сообщение от Аноним (52), 21-Июн-22, 13:01   +/
в Zram сжатие эффективное, а вот скорость - нет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #55

53. Сообщение от Аноним (36), 21-Июн-22, 13:02   +/
Иногда своп своим своим наличием увеличивает время беспроблемного аптайма до месяцев, а вот попытки его отключать приводят к тому, что памяти часто и внезапно начинает не хватать. Далеко не все операции требуют много памяти постоянно, временно можно поступиться перетеканием в своп огромной бесполезной кучи фоновых данных. Да и в целом, когда память используется под файловые кэши, это куда полезнее старых не востребованных данных оказывается. Есть ситуации, когда отключение свопа целесообразно (в основном критерий недопустимость любых задержек по этой причине), но на практике такие задачи ещё придётся поискать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #81

54. Сообщение от Аноним (26), 21-Июн-22, 13:06   +8 +/
Разрешите вам немножечко порвать шаблон. Спасибо за разрешение.

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #66

55. Сообщение от Аноним (36), 21-Июн-22, 13:06   +/
> в Zram сжатие эффективное, а вот скорость - нет

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

56. Сообщение от arthi747email (ok), 21-Июн-22, 13:07   +5 +/
Когда прочитал думал они какой то супер пупер метод сжатия придумали. А они придумали ровно то же колво сметаны перекладывать в те же банки, но перекладывать "более сильнее".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

57. Сообщение от VladSh (?), 21-Июн-22, 13:07   +2 +/
Ничё так идея - гробить ресурс SSD ради экономии оперативки...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #62, #67, #72

58. Сообщение от Анонимemail (62), 21-Июн-22, 13:09   +1 +/
Не понимаю, зачем это всё. Разве своп не так же работал? Это позор конечно. Но если своп работал не так, значит надо было его доработать, а не городить велосипеды.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #130

59. Сообщение от Онаним (?), 21-Июн-22, 13:09   +/
"Если бы они выбрали компилируемый язык"
... то настолько масштабного сервиса не было бы никогда. Был бы концепт за концептом.
В этом всё веселье моднявых язычков. Реальные же серьёзные внедрения делаются на других.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #60

60. Сообщение от Онаним (?), 21-Июн-22, 13:10   +/
Ну а на сях фейсбук написать - не, можно наверное, но оно ж онлайновое, потом всё это поддерживать, отлаживать, деплоить... это просто ад трешовый.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

61. Сообщение от Онаним (?), 21-Июн-22, 13:12   +/
А потом приложение внезапно по какому-то редкому запросу решает сходить в "холодную" память, и ВЕСЕЛУХА.
Не, в масштабах фейсбука всё понятно, там 99% хипа висят сутки мёртвым грузом в качестве кеша для очень редких обращений. Но за пределами применимость так себе. Это как RocksDB - на определённых применениях оно более-менее годно, но за их пределами - вообще неприменимо.
Ответить | Правка | Наверх | Cообщить модератору

62. Сообщение от Анонимemail (62), 21-Июн-22, 13:14   +/
Не гробить, а использовать. Если так получается выгоднее, то почему нет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #109

63. Сообщение от Аноним (63), 21-Июн-22, 13:31   +2 +/
> на более дешёвые накопители, такие как NVMe SSD-диски

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

Ответить | Правка | Наверх | Cообщить модератору

64. Сообщение от Аноним (64), 21-Июн-22, 13:35   +/
> через cgroup2 динамически корректирует ограничение памяти

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

Ответить | Правка | Наверх | Cообщить модератору

65. Сообщение от lockywolf (ok), 21-Июн-22, 13:37   +1 +/
Зачем _вообще_ эвиктить исполняемые страницы? 90% памяти -- это же ресурсы, а не код.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #101

66. Сообщение от Медоед (?), 21-Июн-22, 13:45   +1 +/
Все верно, есть т.н. Lean методология, когда стадия стенда или прототипирования ставит в приоритет время и гибкость.

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #93

67. Сообщение от Аноним (67), 21-Июн-22, 13:50   –2 +/
Как там, в 2010-х?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

68. Сообщение от Аноним (68), 21-Июн-22, 13:53   –6 +/
>Сначала пишут жирный софт, а потом пытаются эффеективно свапиться. 2022.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #85

70. Сообщение от ryoken (ok), 21-Июн-22, 13:55   +1 +/
А можно плз перевод терминов? С целью повышения уровня образованности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #84, #87, #96

71. Сообщение от Ананоним (?), 21-Июн-22, 13:55   +3 +/
О как! А нам предлагали продукты, написанные на С++ и они даже работали? Хм. То ли нам такие продукты плохие продавали, то ли у них программисты негодные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

72. Сообщение от Аноним (68), 21-Июн-22, 14:02   +/
Они-то себе могут и MLC позволить. А вот для простых линуксоидов(-гентоводов) они исчезли из продажи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #160

77. Сообщение от Аноним (81), 21-Июн-22, 14:33   +1 +/
"позволяющей значительно экономить оперативную память на серверах за счёт вытеснения не требуемых для выполнения работы вторичных данных на более дешёвые накопители, такие как NVMe SSD-диски"

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

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #95, #107

80. Сообщение от Аристарх (??), 21-Июн-22, 14:43   +/
Там не гугл виноват. Просто почитай сам стандарт HTML - охренеешь, сколько всего вычурного и костылеподобного надо поддерживать! А ещё ведь есть CSS, JS, мультимедия, отладочные средства... не удивлён, что chrome.dll занимает 170МБ! Хотя многовато для софта, да.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #103

81. Сообщение от Аноним (81), 21-Июн-22, 14:45   +/
> Иногда своп своим своим наличием увеличивает время беспроблемного аптайма до месяцев, а
> вот попытки его отключать приводят к тому, что памяти часто и
> внезапно начинает не хватать. Далеко не все операции требуют много памяти
> постоянно, временно можно поступиться перетеканием в своп огромной бесполезной кучи фоновых
> данных. Да и в целом, когда память используется под файловые кэши,
> это куда полезнее старых не востребованных данных оказывается. Есть ситуации, когда
> отключение свопа целесообразно (в основном критерий недопустимость любых задержек по этой
> причине), но на практике такие задачи ещё придётся поискать.

Да, вот только частенько бывает обратное, свапование зачастую означает, что система плотно и глубоко "задумывается", без возможности дать ей дополнительную задачу, чисто потому, что по какой-то интересной причине ОЗУ не забито, а система в свапе что-то ворочает со скоростью эстонской черепахи.

Как бы ни был быстр ЖД, ОЗУ всё равно пока ещё быстрее, и зачастую свап ненужен, если ОЗУ физически хватает под задачи и даже вреден, для скорости работы.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #82

82. Сообщение от Аноним (81), 21-Июн-22, 14:47   +/
>[оверквотинг удален]
>> это куда полезнее старых не востребованных данных оказывается. Есть ситуации, когда
>> отключение свопа целесообразно (в основном критерий недопустимость любых задержек по этой
>> причине), но на практике такие задачи ещё придётся поискать.
> Да, вот только частенько бывает обратное, свапование зачастую означает, что система плотно
> и глубоко "задумывается", без возможности дать ей дополнительную задачу, чисто потому,
> что по какой-то интересной причине ОЗУ не забито, а система в
> свапе что-то ворочает со скоростью эстонской черепахи.
> Как бы ни был быстр ЖД, ОЗУ всё равно пока ещё быстрее,
> и зачастую свап ненужен, если ОЗУ физически хватает под задачи и
> даже вреден, для скорости работы.

Свап был создан в те времена, когда ОЗУ объективно не хватало физически и когда упавший и незавершившийся корректно процесс, был удшим исходом, нежели намного более медленное, но всё же разрешение и завершение процесса корректным образом.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #83

83. Сообщение от Аноним (81), 21-Июн-22, 14:47   +/
>[оверквотинг удален]
>>> отключение свопа целесообразно (в основном критерий недопустимость любых задержек по этой
>>> причине), но на практике такие задачи ещё придётся поискать.
>> Да, вот только частенько бывает обратное, свапование зачастую означает, что система плотно
>> и глубоко "задумывается", без возможности дать ей дополнительную задачу, чисто потому,
>> что по какой-то интересной причине ОЗУ не забито, а система в
>> свапе что-то ворочает со скоростью эстонской черепахи.
>> Как бы ни был быстр ЖД, ОЗУ всё равно пока ещё быстрее,
>> и зачастую свап ненужен, если ОЗУ физически хватает под задачи и
>> даже вреден, для скорости работы.
>был *худшим исходом, нежели...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

84. Сообщение от Замир Закиев (?), 21-Июн-22, 14:54   +2 +/
это стандартные термины в каратэ (для общения, не для обозначения техник)

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #99, #154

85. Сообщение от _kp (ok), 21-Июн-22, 14:54   +1 +/
>> байтики считать

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #102

86. Сообщение от _kp (ok), 21-Июн-22, 14:57   –1 +/
Они улучшили своп
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

87. Сообщение от _kp (ok), 21-Июн-22, 15:01   +1 +/
Там каламбур на тему одной игры.
Замена политнекорректного OOMKiller на Яндере. Что тот же киллер, но с любовью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

91. Сообщение от Аноним (91), 21-Июн-22, 15:29   +/
>и оказывается, что он был пустым, просто занятым. Этому багу уже лет 20.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #94

93. Сообщение от funny.falcon (?), 21-Июн-22, 15:33   +1 +/
Reddit, написанный на python
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #168

94. Сообщение от Аноним (36), 21-Июн-22, 15:37   +/
>No results found for zswap discard.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #143

95. Сообщение от Роман (??), 21-Июн-22, 15:44   +/
интересный вопрос - вы считаете их почему-то должна заботить "вечная" жизнь дисков, они как-то прикипели к ним душой? или их больше должно заботить залезть в нарастающий рынок VR на 100500 миллиардов и надо успеть сформировать его на своих правилах, а там уже на сдачу поменять просто все диски (ну чего бы нет, от доброты душевной) или вообще на Optane переехать (может у них уже Optane местами конечно)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

96. Сообщение от Kuromi (ok), 21-Июн-22, 15:50   +/
Тут надо прояснить откуда берется семпай и кохай - у японцев в школах есть всякие клубы и прочие местные "комсомольские организации" в которых совместно участвуют ученики разных годов обучения, поэтому и появляется меду ними взаимодецствие с делением на "старший"\"младший". Потом такая модель отчасти тянется и более взрослую жизнь.
У нас в Дикой такое ученики разных годов обычно никак не взаимодействуют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #104

97. Сообщение от Аноним (97), 21-Июн-22, 15:52   +1 +/
В Мозилле не в Расте дело, а в "эффективных менеджерах", которые распилили почти весь бюджет между собой и половину разрабов уволили. Есть ощущение, что Мозиллу ведут к планируемому банкротству и поглощению Гуглом или Майкрософтом, с выплатой "золотых парашютов" менеджменту. Ну как с Нокией было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #133

98. Сообщение от Аноним (98), 21-Июн-22, 15:56   –1 +/
Бери мс - там и интерфейс человеческий и есть WSL что тот же линупc.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

99. Сообщение от bq (?), 21-Июн-22, 15:59   +1 +/
незнаю каратэ, начать разьве не hajime?
в голодных сёстрах помойму было, hajimaru you!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

101. Сообщение от Аноним (101), 21-Июн-22, 16:01   –2 +/
100500 подгруженых либ, в которых реально используется 0.1% кода не согласны. И код инициализвции тоже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

102. Сообщение от Аноним (68), 21-Июн-22, 16:18   –2 +/
Причём здесь каналы связи? Я имел ввиду ОЗУ вычислительных устройств с полноценным ЦПУ и их софт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #125

103. Сообщение от Аноним (-), 21-Июн-22, 16:38   –1 +/
XHTML?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #132

104. Сообщение от ryoken (ok), 21-Июн-22, 16:40   +/
Насколько я помню из прочитанного - у японцев ообще сильно поделённое по возрасту\соц. положению общество, редко кто кому может напрямую обращаться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #114

105. Сообщение от a_kusb (ok), 21-Июн-22, 16:40   +3 +/
Так когда набрали и нужно было переписывать на компилируемом.
А ещё социальная сеть кажется мне простой программой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #140

106. Сообщение от Аноним (106), 21-Июн-22, 16:47   –1 +/
Я видел их код. За такой код надо запрещать работать в индустрии навсегда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #166

107. Сообщение от Аноним (107), 21-Июн-22, 16:54   +/
>С каких это пор с ограниченным циклом перезаписи SSD стали дешевле "вечной" ОЗУ?!
>Я где-то проспал техническую революцию в вопросе "вечной" жизни ssd?

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #121

108. Сообщение от Бывалый смузихлёб (?), 21-Июн-22, 16:55   +/
> А как не подскажите? MacOS убивает просто, 32GiB оператоса, i9 а тормозит
> как черте знает что -_-"
> А в компании выбор либо M$ либо MacOS из-за антивирусов и прочей
> фиготени.

Причин для тупни на яблоке может быть полно, но вот что по памяти:
Для начала отключить SIP
После - в терминале ввести
> sysctl -a vm.compressor_mode

Если выдаёт 4( по умолчанию ) - валит на диск, нужно переключить в 2
Перед изменением на всякий получить текущий список аргументов
> nvram boot-args

И указать что нефиг использовать диск если есть оперативка!
> sudo nvram boot-args="vm_compressor=2"

Или, скорее, даже так
> sudo nvram boot-args="выхлоп_от_запроса_списка_параметров_загрузки_предыдущего_шага vm_compressor=2"

Изменения вступают в силу после перезагрузки. Если всё норм, то sysctl -a vm.compressor_mode должна выдавать 2

Если работает на хакинтоше, то пытаться просто менять nvram бесполезно - исправлять надо в настройках опенкор( там одно из полей - аккурат кагбэ_nvram_для_яблока )

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

109. Сообщение от VladSh (?), 21-Июн-22, 16:57   +1 +/
Считать надо. Но я сильно сомневаюсь. Во-1, - оператива, считай, вечная - капитальные затраты единожды и всё, а SSD, даже самый лучший, менять надо, тем более при таком сценарии использования. Во-2, народ наоборот часть данных на RAM-диски перенести пытается далеко не зря.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #134

110. Сообщение от Бывалый смузихлёб (?), 21-Июн-22, 16:58   +/
>> А в компании выбор либо M$ либо MacOS

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

112. Сообщение от КО (?), 21-Июн-22, 17:35   +1 +/
То есть теперь накопители будут изнашиваться ещё быстрее?
А смысл тогда в увеличении производительности засчет доп. затрат?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #113

113. Сообщение от Аноним (107), 21-Июн-22, 17:52   –1 +/
Знаешь способ увеличения производительности без доп. затрат? Патентуй скорее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #116

114. Сообщение от Kuromi (ok), 21-Июн-22, 18:04   +/
> Насколько я помню из прочитанного - у японцев ообще сильно поделённое по
> возрасту\соц. положению общество, редко кто кому может напрямую обращаться.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

116. Сообщение от Попандопала (?), 21-Июн-22, 18:28   +/
Уже же все запатентовали. Мульен терабайтный свап файл выгоднее, чем столько рамы покупать. Не удивлюсь если сейчас проблемы с производством, доставкой колбасы.D Говорили же инфу у нас локализуйте, так нет же...XD
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

118. Сообщение от anonymous (??), 21-Июн-22, 18:42   –1 +/
На самом деле уже в те времена был очень фичастый компилируемый язык со сборщиком мусора - Haskell. Единственный минус - порог вхождения высокий. Мало кто из пхпшников осилить способен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

119. Сообщение от anonymous (??), 21-Июн-22, 18:52   +3 +/
Кохай - это "люби" по-украински?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

121. Сообщение от Аноним (43), 21-Июн-22, 19:01   +/
> регулярно менять сдохшие SSD дешевле

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107 Ответы: #122, #123

122. Сообщение от Аноним (43), 21-Июн-22, 19:02   +/
P.S. сначала продадут, потом потеряют, чтобы на ковре в Конгрессе не сильно пинали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121

123. Сообщение от Аноним (107), 21-Июн-22, 19:13   +/
Именно так!
В шкале приоритетов на первом месте прибыль, а хомячки - на последнем
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121

124. Сообщение от Аноним (124), 21-Июн-22, 19:28   –1 +/
> экономить оперативную память на серверах за счёт вытеснения не требуемых для выполнения работы вторичных данных

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

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #129, #131, #136

125. Сообщение от Аноним (125), 21-Июн-22, 19:53   +/
А какой из стандартных алгоритмов сортировки выберете для строкового массива на пару Тб?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #138, #142

126. Сообщение от Аноним (127), 21-Июн-22, 20:00   +/
Для этого разработчик Google уже несколько лет пытается включить патч в стандартное ядро Linux: https://lore.kernel.org/lkml/20220614071650.206064-1-yuzhao&...

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

127. Сообщение от Аноним (127), 21-Июн-22, 20:03   +/
Вы из тех, кто считает сервер с 256 ГБ RAM для раздачи торрентов минимумом?

https://github.com/arvidn/libtorrent/issues/6667#issuecommen...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #135

128. Сообщение от Аноним (127), 21-Июн-22, 20:05   +/
Быть может, у вас включён и zram, и zswap одновременно? Я встречал описываемый вами баг именно в таком сценарии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

129. Сообщение от ыы (?), 21-Июн-22, 20:05   +/
>Как они там оказались?

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124

130. Сообщение от Аноним (127), 21-Июн-22, 20:10   +/
Текущая версия swap в линуксе работает, прямо скажем, неоптимально. Там используется простой LRU-механизм, с разделением только на данные (анонимную память) и файловый кеш.
Есть два подхода к его улучшению, оба до сих пор не приняты в ядро:

1. Патч под названием le9: https://github.com/hakavlad/le9-patch
Защищает (как мягко, так и жёстко) какое-то фиксированное количество файлового кеша в оперативной памяти. Очень полезно для десктопов, позволяет выгружать гигабайты в своп без зависаний и тормозов системы.

2. Более продвинутая версия предыдущего патча с автоматическим определением количества важного файлового кеша MG-LRU, добавляющая понятие времени к LRU: https://lore.kernel.org/lkml/20220614071650.206064-1-yuzhao&...
Применяется в Chrome OS и Android.
Подробное описание: https://lore.kernel.org/all/20220614071650.206064-15-yuzhao&.../

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

131. Сообщение от Аноним (127), 21-Июн-22, 20:12   +/
Только не читайте про стандартный аллокатор malloc в glibc: сильно будете удивлены, что он почти не отдаёт данные при выполнении операции free().
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #137

132. Сообщение от Аноним (43), 21-Июн-22, 20:13   +/
PDF. Он изначально был кандидатом для веб, но кое-кто подсуетился, и теперь имеем дерьмохтмл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

133. Сообщение от Аноним (43), 21-Июн-22, 20:15   +/
> Ну как с Нокией было.

У Нокии был фатальный недостаток: она находилась не в Штатах.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

134. Сообщение от ыы (?), 21-Июн-22, 20:20   +/
Посчитайте пожалуйста. А то у нас у всех лапки....
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

135. Сообщение от suffix (ok), 21-Июн-22, 20:28   +/
Мне кажется что Вы со своим вопросом промахнулись - он явно не ко мне.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127

136. Сообщение от YetAnotherOnanym (ok), 21-Июн-22, 20:50   –1 +/
Щас прибежит один из Анонимов и будет с пеной у рта доказывать, что только так и можно написать успешный проект.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124

137. Сообщение от YetAnotherOnanym (ok), 21-Июн-22, 20:55   +/
Надо же... А я когда-то написал демона на сях, у которого в цикле было malloc в начале и free в конце, так он месяцами крутился и не тёк. А должен был бы течь, если free не освобождает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #141

138. Сообщение от Аноним (138), 21-Июн-22, 21:05   +/
Выберу вот такой.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125

139. Сообщение от Аноним (139), 21-Июн-22, 21:28   +/
> Установочный файл весит всего 10 Мб.

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

140. Сообщение от стоячок (?), 21-Июн-22, 21:41   +/
кажется
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

141. Сообщение от Аноним (127), 21-Июн-22, 22:16   +/
Современные версии аллокатора в glibc не отдают память в ОС, выделенную на хипе, если её нельзя уменьшить через sbrk, а аллокации через новые регионы требуют выделения сразу большого количества памяти за раз (от 16 МБ, если не ошибаюсь).
Баг от 2006 года: https://sourceware.org/bugzilla/show_bug.cgi?id=2531
https://stackoverflow.com/a/48652734
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #149

142. Сообщение от _kp (ok), 21-Июн-22, 22:36   +3 +/
> А какой из стандартных алгоритмов сортировки выберете для строкового массива на пару
> Тб?

Стандартные маловероятно.

Была не очень давно задача не про сортировку, а поиск и выборку значений из базы. Типа встроенный прибор, ни вменяемой структуры, ни полезного индекса. С ростом аппетитов базы распухли, и операции выборки стали переваливать за 40 секунд.
Носитель - флешка, скорости ограничены, в ОЗУ много не накэшируешь. Плюс могут быть сбойные записи, ннедостающие параметры, вместо еоторвх надо выдать что то другое.
Поставили задачу, сделать работу хоть как то быстрее. Если вдвое быстре будет, то это предел мечтаний.
До алгоритмов не сам дошел, воспользовался помощью математиков.
И, после оптимизации...
время операций стало 0.02 - 0.3 секунд, в лучшем и хуждем случаях.
Более, чем в тысячу раз ускорил. ;)
На том же желелезе.

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #159

143. Сообщение от Аноним (143), 21-Июн-22, 23:13   +/
Именно тем и поможет - без опции discard не происходит высвобождение страниц zswap, они продолжают висеть занятыми и после протухания.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

144. Сообщение от Аноним (144), 21-Июн-22, 23:40   +/
Прочитал комментарии и не понял, есть ли какие-то претензии к продукту, кроме того, что его написал фейсбук?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #158

145. Сообщение от fuggy (ok), 22-Июн-22, 00:31   +1 +/
Senpai, yamete kudasai, it doesn't fit. Out of memory.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

148. Сообщение от Аноним (148), 22-Июн-22, 06:51   +/
на что только не пойдет мордокнига для своих php извращений
Ответить | Правка | Наверх | Cообщить модератору

149. Сообщение от YetAnotherOnanym (ok), 22-Июн-22, 07:57   +/
Гы... Теперь олдфаги могут кряхтеть, что "раньше и malloc/free нормально работали".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141

151. Сообщение от Serghei (?), 22-Июн-22, 10:09   +/
барин/холоп
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #167

154. Сообщение от нгеро (?), 22-Июн-22, 12:26   +/
ну так поди, сенпай он для кохая сенпай, а не для сенсея. Для сенсея он такой же кохай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

155. Сообщение от Первая буква (?), 22-Июн-22, 14:24   +1 +/
> А как набрали пользователей

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #156

156. Сообщение от a_kusb (ok), 22-Июн-22, 18:37   +/
А что там плохого в политике? Не слежу за этим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155

157. Сообщение от Аноним (158), 23-Июн-22, 00:19   +/
Переизобрели своп, мое почтение всем велосипедостроителям мира
Ответить | Правка | Наверх | Cообщить модератору

158. Сообщение от Аноним (158), 23-Июн-22, 00:20   +/
Технологии свопа уже лет 30 если не больше, и во всех осях она есть по дефолту, на кой нужна подделка от мордокниги?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144

159. Сообщение от pavlinux (ok), 23-Июн-22, 13:17   +2 +/
> применили алгоритм учитываюший характер данных,

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

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

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

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

)))

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #161

160. Сообщение от InuYasha (??), 23-Июн-22, 17:45   +/
даже мыльце от такого не спасёт в долгосрочной перспективе, и даже сальце (SLC).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

161. Сообщение от _kp (ok), 23-Июн-22, 19:15   +/
> Открою секрет...

Согласен по пунктам 1 и 3 полностью, и по 2му на 30%. :)

Нельзя в готовом, и по сути чужом проекте, который работает, все похерить и сделать правильно.
К элегантным костылям претензии есть? Да, нет, они шикарны.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159 Ответы: #164

162. Сообщение от none7 (ok), 23-Июн-22, 19:51   +/
>Исходя из того что стоимость времени разработчика больше стоимости железа.  

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #165

163. Сообщение от Отражение луны (ok), 24-Июн-22, 04:56   +/
Уже. Долго же до вас тренды доходят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

164. Сообщение от pavlinux (ok), 24-Июн-22, 14:29   +1 +/
>> Открою секрет...
> Согласен по пунктам 1 и 3 полностью, и по 2му на 30%.
> :)
> Нельзя в готовом, и по сути чужом проекте, который работает, все похерить
> и сделать правильно.
> К элегантным костылям претензии есть? Да, нет, они шикарны.

Найти чупакабру на ноевом ковчеге - O(N)
Найти чупакабру в зоопарке - O(1)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

165. Сообщение от Аноним (165), 24-Июн-22, 15:44   +1 +/
Так не бывает что у тебя ЦОДЫ и тысячи серверов по всему миру и один разработчик.  Если ты разместился по всему миру значит твои фичи нужны пользователям.  А для этого надо много разработчиков и много времени. А если тебе надо писать на С++ то тебе надо еще больше времени и еще больше разработчиков. Но зачем когда можно писать на пыхе.  Ну и пересчитай что в США один средний разработчик стоит 100000 долларов. А в Фейсбуке не меньше 10000 разработчиков.  
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162

166. Сообщение от Аноним (165), 24-Июн-22, 15:45   +/
Ещё один любитель искусства ради искусства.  
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106

167. Сообщение от Oxyd76 (?), 25-Июн-22, 11:09   +/
Никита Сергеич Михалков. Перелогиньтесь!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151

168. Сообщение от andrei (??), 26-Июн-22, 12:13   +/
Какие в ж...пу фичи в Твиттере?! Увеличение сообщения больше 160 символов?! Доска сообщений она и есть доска...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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