Свежие комментарии
| Title | Comment |
|---|---|
| Про тот же паттерн я и говорил: если очередь на запись больш |
Про тот же паттерн я и говорил: если очередь на запись больше чего-то там (для каждого приоритета - отдельно!), то незаметно сделать запись блокирующей, и оно приостановит все что нужно. Просто парадигма "памяти неограниченно, если что - виртуальной памяти нам хватит" она в ряде ситуаций очень misleading. Учитывая то, как люди оптимизируют strlen 8-) |
| >В виндоус граждане тоже жалуются на что-то похожее http://c |
>В виндоус граждане тоже жалуются на что-то похожее http://ctpeko3a.livejournal.com/506520.html |
| Во, теперь увидел! Спасибо! Хотя разбираться сейчас не буду |
Во, теперь увидел! Спасибо! Хотя разбираться сейчас не буду, жарко, моск пухнет. Но пометку сделал. |
| Не, кэш, понятно, в свап не выгружается. Ну то есть не долже |
Не, кэш, понятно, в свап не выгружается. Ну то есть не должен бы. Но может вытеснить странички спящего приложения. Причем, веселуха, по идее, может быть не столько от вытеснения, сколько от того, что у приложения что-то аллоцировано, но не используется (и потому отсутствует), а тут оно захотело его поюзать - а все пожрал кэш. И идея иметь для cp специальный сисколл или вызов - она правильная, в виндах так и сделано. Но не cp же единой, скажем если я занимаюсь сортировкой (слиянием) терабайта данных в уголке - это тот же паттерн (несколько потоков чтения, один - записи) и те же грабли. С виндой, как я уже писал в прошлом посте я на нечто подобное наступаю при heavy IO иногда (уже давно не было что-то) но с существенным отличием: замирание не полное, запущенные программы работают и даже файловый IO какой-то делают (браузер кэш пишет и все такое), проблемы с запуском новых процессов - это да. Правда до того, чтобы 700G писать по USB я не дохожу :), если больше чем гигов 30-40 на внешний диск, то я не поленюсь eSATA-крэдл достать. Но симптомы у винды близкие по смыслу, да: память занимается близко к 100% (это из 12-16 гигов то), свапа у меня практически нет, потому его и нет, а на что ушла память и зачем - понять не удается. |
| <q>И там не вижу. Дай точную ссылку (хинт - у заголовка кажд |
И там не вижу. Дай точную ссылку (хинт - у заголовка каждого коммента есть собственный URL c #comment-ID). b00ter отвечал на самом деле мне, а получилось -- кике, сравни с жж. это не единственный случай. Там вот есть, что если в стандалоне отвечали на ЖЖ-шный камент, то образуется своя ветка (которой нет в ЖЖ), которая может быть выше ЖЖ-шного продолжения. Но я не вижу в этом проблемы. |
| И там не вижу. Дай точную ссылку (хинт - у заголовка каждого |
И там не вижу. Дай точную ссылку (хинт - у заголовка каждого коммента есть собственный URL c #comment-ID). Там вот есть, что если в стандалоне отвечали на ЖЖ-шный камент, то образуется своя ветка (которой нет в ЖЖ), которая может быть выше ЖЖ-шного продолжения. Но я не вижу в этом проблемы. |
| Если бы для файла открытого на чтение файловый кеш выгружалс |
Если бы для файла открытого на чтение файловый кеш выгружался в свап - был бы совсем epic fail. Проблема скорее в имплементации cp - оно же по сути как pipe, должно переставать читать когда длина очереди на запись становится больше какой-то (=< допустимый размер дискового кеша при имеющемся профиле памяти), и таким образом не усугублять проблему. Подумав еще немного, могу представить себе что при мелких файлах - файловый кеш вымывается страницами памяти случайным образом, как и обычная память, а вот при копировании заведомо больших файлов - буфер надо делать линейным как очередь, и освобождать хвост сразу после того как сдвинулось окно, т.е. это другая стратегия кеширования. Проблема многопоточной записи соответственно тоже должна решаться эффективно через отключение кеширования записи на диск при увеличении очереди записи больше какой-то - оно само тогда выстроится когда исчезнет асинхронность (но тут тоже надо не переборщить, чтобы системные процессы желающие записать одну строчку в лог не зависли...) В виндоус граждане тоже жалуются на что-то похожее http://ctpeko3a.livejournal.com/506520.html |
| видимо предпредыдущий был настолько обширным, что создал впе |
видимо предпредыдущий был настолько обширным, что создал впечетление что смотрю два. в предпредыдущем точно есть. |
| Предыдущий посмотрел - проблемы не увидел. |
Предыдущий посмотрел - проблемы не увидел. |
| не знаю что ты имеешь ввиду, может ТРОЕ. ну глянь в предыду |
не знаю что ты имеешь ввиду, может ТРОЕ. ну глянь в предыдущих двух постах как треды нарисованы и кому на самом деле ответ предназначался. вероятно при импорте ветки из жж при наличии камента в блоге второй и последующий каменты жжшной ветки цепляются не к жжшному каменту, а к каменту в блоге. |
| Что, ОБА? У меня в стандалон-блоге ID комментариев уже под |
Что, ОБА? У меня в стандалон-блоге ID комментариев уже под 20к. Может быть ты покажешь поточнее? |
| у тебя в стандалон-блоге треды бьются. |
у тебя в стандалон-блоге треды бьются. |
| http://download.intel.com/design/network/applnots/322819.pdf |
http://download.intel.com/design/network/applnots/322819.pdf Вообще, для 10G, как я понял, идея заключается в том, чтобы сделать несколько очередей силами карты (многие - умеют) и повесить разные CPU на разные очереди/IRQ. Только вот если по линку ходит один поток данных (репликация 1-1 или просто файлсервер), то это не спасет. |
| Это плохо? |
Это плохо? |
| А можно ссылочку на источник данных? |
А можно ссылочку на источник данных? |
| Да и для процессов есть. |
Да и для процессов есть. |
| Самая жесть на тему 10G+linux написана у интела: "чтобы умен |
Самая жесть на тему 10G+linux написана у интела: "чтобы уменьшить latency, загрузите вашу multi-core систему в single-core режиме". Потому что иначе ядра друг другу кэши инвалидируют. |
| Ну для прерываний то есть.... |
Ну для прерываний то есть.... |
| Не виду препятствий. CPU affinity в Линуксе нет, но, справед |
Не виду препятствий. CPU affinity в Линуксе нет, но, справедливости ради, надо отметить, его много где нет. |
| А что тут пояснять то? Вот у меня приезжают пакеты с одного |
А что тут пояснять то? Вот у меня приезжают пакеты с одного NIC. Можно ли их обрабатывать разными CPU core, по очереди или там по готовности core ? |
| Поясните, пожалуйста. |
Поясните, пожалуйста. |
| Одна сетевая карта - одно прерывание - одно процессорное ядр |
Одна сетевая карта - одно прерывание - одно процессорное ядро? Правильно? |
| А что такое "стек не масштабируется"? |
А что такое "стек не масштабируется"? |
| А, вижу что давно :-) Он теперь часть кернела, апгрейдится |
А, вижу что давно :-) Он теперь часть кернела, апгрейдится вместе с кернелом, ничего специально ставить и переставлять не надо |
| RHEL6? там правда гцц 4.4.5 |
RHEL6? там правда гцц 4.4.5 |
| Я видел. Сделав XFS на 16Т. Результат оказался невосстановим |
Я видел. Сделав XFS на 16Т. Результат оказался невосстановим (но воспроизводим). |
| И чего, кажды год на куче серверов переставлять KVM? |
И чего, кажды год на куче серверов переставлять KVM? |
| XFS never again. Когда файловая система при размере тома в |
XFS never again. Когда файловая система при размере тома в 16Т просто сделала wrap around и молча пошла себя записывать с начала, я понял что добровольно - больше никогда. |
| Стек не масштабируется, планировщик можно менять, но непонят |
Стек не масштабируется, планировщик можно менять, но непонятно на что. Файловые системы - просто говно. В боевых условиях можно использовать ext3/4, а они любят иногда уйти в свой БВМ и не выходить оттуда полчаса. За это время я успеваю потерять килограмм рекордингов. |
| Может быть, но как можно гоняться за распоследним варезом в |
Может быть, но как можно гоняться за распоследним варезом в продакшене на три сотни серверов? |
Pages
