В статье речь идёт, как я понял, во всех случаях о попытках попользоваться ipv6 при его отсутствии. По всей видимости речь идёт о ip6to4, а не о ipv6.
У каждого туннельного провайдера свои особенности, наверное стоило разобраться в проблемах и их решить, а не просто включать/выключать.
Да и не стоит использовать ipv6to4 без острой необходимости. Туннель всегда хуже работает.
Для туннелей стоит урезать mtu, т.к. при обилии пакетов могут быть потери, а пакет о недоставке не пролезет в туннель и всё захлебнётся. Иногда нужно ограничить скорость удерживая в очереди пакеты на своём роутере чтобы избежать потерь пакетов. И т.д. и т.п.
Это не проблема ipv6, а нежелание копнуть поглубже.
Провайдеры проблемы в своих сетях начнут решать только при массовом использовании. Сегодня в России у топ провайдеров особых проблем не наблюдается. Только несуразные маршруты.
Из моих наблюдений в период COVID-19, по ipv4 трафик в Европу с трудом прорывается, а ipv6 стабильно работает. Возможно связано с иными путями и более новым оборудованием.
Сервис должен в первую очередь делаться для нормальных людей, а не для борьбы со злодеями. Пользователь не должен страдать.
Если кнопка называется "Спам", то она должна отправлять в спам. Если называется "Отписаться", то она должна именно отписывать, а не то что mail.ru захотелось. Что написано, то и должно делаться. Не нужно никого вводить в заблуждение.
Mail.Ru при нажатии на отписаться делать 2 действия сразу: стучит по ссылке в заголовке List-Unsubscribe и шлёт ARF письмо на адрес указанный в настройках FeedLoop Back. Зачем?!
Я думаю если например репутация больше 1.0, то не показывать кнопку "Отписаться" вообще.
Если "Отписаться" возвращает код 4xx,5xx HTTP/SMTP в >10% процентах случаях, то скрыть кнопку "Отписаться".
Если большой процент пользователей кнопку "Отписаться" жмут в новых письмах присланных после предыдущего нажатия, тоже не показывать.
В "Спам" же отправлять только те что пользователь посчитал спамом, т.е. нажал кнопку "Спам".
Примерно такая политика должна отсеять недобросовестных рассыльщиков.
Скорее всего сейчас работает так как работает потому что реализуется за пару минут, а чтобы работало как надо нужно проделать большой объём работы. Будем надеяться что в mail.ru найдут время и все сделают.
согласен. просто это единственный пост на русском где разобран пример. и он меня ввёл в заблуждение, я уже было расстроился посчитав что из-за такого ограничения pg_rewind не годится для задачи быстрого восстановления мастера после падения. однако мне таки удалось его завести описанным выше способом.
на текущий момент pg_rewind также не перематывает если postgres остановлен аварийно. полтора года назад тоже ничего не мешало сделать так чтобы аварийно упавший postgres был остановлен штатно.
Известные ограничения: Еще одно существенное ограничение, мастер должен быть выключен штатно.
никакого ограничения здесь нет.
порядок действий таков.
1. выдергиваем мастер из розетки
2. переводим слейв в мастер
3. старый мастер втыкаем в розетку
4. запускаем старый мастер, он делает recovery
5. останавливаем старый мастер корректно
6. делаем на старом мастере recovery.conf
7. запускаем pg_rewind и он успешно перематывает
8. запускаем старый мастер(он же новый слейв) и он накатывает изменения с нового мастера
нужно иметь инструмент дающий максимально приближённые настройки, от которых уже отталкиваться, а не гадать на кофейной гуще. pgtune действительно тот инструмент который должен пригодиться даже бывалому.
комментарий действительно упустил. сейчас значения для текущего набора входных данных соответствуют. не хватает исходных данных, не плохо бы ещё оттолкнуться от тех параметров что я описал ранее.
Что касается дискового кэша. Если база 1 ТБ с большим объёмом горячих данных, врядли на серваке будет ещё что-то кроме postgres. используя пулер, например pgbouncer, мы можем точно контролировать кол-во воркеров postgres, а значит можем точно знать сколько максимум памяти это займёт. в этом случае нет смысла страховаться дисковым кэшем в ущерб shared_buffers. Данные в дисковом кэше неизбежно дублируются в shared_buffers, т.е. одни и теже данные хранятся в 2х местах одновременно что крайне не эффективно ввиду того что оперативной памяти итак мало.
Что касается checkpoint. простым языком checkpointer process непрерывно монотонно пишет изменённые страницы на диск пока не достигнет checkpoint_timeout или размера wal 16Мб. пишет на диск он те страницы которые не используются(вероятно не используются) чтобы не блокировать процесс выполнения запросов воркерами. все изменённые страницы обязательно должны быть записаны на диск, т.е. если воркеру нужна страница которой нет в разделяемой памяти(shared_buffers), то она берётся с диска и записывается в свободное место разделяемой памяти, а при отсутствии места вытесняет другую не изменённую(или уже записанную chekpointer process на диск). Если в shared_buffers все страницы изменены, то воркерам придётся подождать(для многих систем как правило ждать недопустимо) пока checkpointer process что-нибудь запишет на диск. Чем больше shared_buffers, тем меньше вероятность того что придётся ждать checkpointer process. Вообще если wal'ы пишутся на другие диске, то checkpointer process пишет почти в реальном времени на достаточно большой скорости без iowait. Объём данных которые пишет на диск checkpointer process зависит только от кол-ва данных которые были изменены запросами типа insert, update и т.д., но никак не от размера shared_buffers.
Цитата из рассылки это из области «Люди говорят». Но когда пытаешься найти таких людей чтобы с ними это обсудить лично, то никак их найти не получается. Как правило в рассылке обсуждается один конкретный случай, на конкретном железе и конкретном ПО(кроме postgres там ещё php, java, python и т. д.) на этой же машине. Во всех 4х пунктам в Вашей цитате есть доля правды, но это конкретный случай.
В документации нигде нет информации о 8 Гб. Не понятно почему вы привязали калькулятор PgTune к этому значению и навязываете людям. Калькулятор должен учесть все основные факторы и выдать приближенные значения для конкретного случая который описал человек заполняя поля в форме PgTune. А Вы во всех случаях банально выдаёте заведомо не правильное единственное значение 8 Гб. Чтобы правильно настроить postgres нужно абсолютно чётко понимать как он это делает. Объясните, пожалуйста, как postgres это делает и почему с 8 Гб он это сделает лучше чем с 600 Гб. Наверняка я в чём то заблуждаюсь, откройте мне глаза, объясните на понятном русском как есть на самом деле без ссылок на фразы где так же нет объяснения.
В калькуляторе нужно учитывать как минимум наличие пулера, максимальное кол-во воркеров, объём оперативной памяти, производительность дисков, объём памяти требуемое другому ПО.
за это отвечает wal_buffers, а не shared_buffers. по умолчанию wal_buffers конечно зависит от shared_buffers, но он не может быть больше 16Мб, да и кто мешает от этой зависимости избавиться. поставите нужное значение и никаких проблем.
в любом случае всё нужно записать на диск, а запись зависит от кол-ва insert, update, delete и т.д., но ни как не от объёма shared_buffers. более того, чем больше shared_buffers тем меньше вероятность того что диск будет задействован на чтение, а значит меньше iowait для записи на диск.
а ещё в shared memory можно посмотреть какие данные там лежат, чего нельзя сделать в дисковом кэше. www.postgresql.org/docs/9.3/static/pgbuffercache.html. это позволяет разработчику оценить и написать запросы так чтобы более эффективно использовать оперативную память, сократить обращения к диску. а если имеется несколько слэйв серверов, то можно на одном слэйве в памяти уложить одни данные, а на другом другие для эффективного использования памяти.
в shared_buffers лежат страницы с данными. если горячих данных 100Гб и shared_buffer 8Гб, то эти 100Гб будут постоянно читаться с диска и записываться в эти 8Гб выкидывая другие данные которые уже наверняка при следующем запросе вновь нужны будут.
конечно с диска физически читаться не будет, будет браться с дискового кэша, но этот миксер создаст огромную нагрузку на процессоры. При 100Гб горячих данных и около 1000 запросов в сек вряд ли этот миксер справится даже на многопроцессорном серваке.
если дать 600Гб shared_buffers, то в памяти сразу будет эти 100Гб горячих и ещё 500Гб иногда используемых данных. не будет обращений в дисковую подсистему, не будет постоянных копирований данных из дискового кэша в shared_buffers
главное чтобы (shared_buffers + (максимальное кол-во postgres воркеров * work_mem) + запас) не превысили объём доступной оперативной памяти, иначе всё начнёт свопиться и будет segmentation fault… так же нужно учесть что на серваке кто-то ещё может использовать оперативную память, например php
включите логирование долгих запросов log_min_duration_statement. ставите как можно больше shared_buffers. затем берёте самые тяжёлые и смотрите план запросов… регулируйте work_mem так чтобы план для этих запросов становился наилучшим, pgadmin это покажет в графическом виде. учтите что слишком большие значения work_mem могут быть бесполезными, т. к. даже самому тяжелому запросу может много и не нужно. затем считаете сколько максимум shared_buffers можно поставить чтобы не засвопилось и ставите это значение.
например цифры из реальной жизни. моя база весит 1 терабайт, из них горячих данных около 100 гигабайт. на сервере 768 Гб памяти. ваш калькулятор предлагает shared_buffers = 8GB. с такими настройками это мёртвый сервер. а вот если shared_buffers = 600GB, то всё теперь будет зависеть от процессоров, которых кстати тоже вечно не хватает.
для новичков конечно и так сойдёт, но этот калькулятор на самом деле пустышка и будет вводить новичков заблуждение и развивает лень читать официальную документацию.
Буквально вчера разбирался почему не работает ховер для невидимого div с фиксированными размерами position: absolute. Добавил пустой onclick и ховер заработал :-)…
Вообще с ховерами там всё плохо, в разные моменты времени он работает по разному, то пропадает если ткнуть мимо, то всегда установлен и никак не снять…
Решал около года назад подобную задачку, но попроще. Была файлопомойка(~10 000 000 файлов) с оригиналами и кропами(делали реальные люди), нужно было избавиться от кропаных файлов(ввиду прогресса стали слишком малы), но записать координаты кропа в sql базу.
Написал скриптик под opencv на c++ и использовал его из php. Просто выводит в консоль x, y, width и height
Больше он конечно похож на memcached чем на redis, как я понял он не сохраняет базу на диск и восстанавливаться не умеет. Единственным плюсом перед memcached вижу блокировки, чего нехватает memcached. И тут возникает вопрос что делает другой клиент если кто-то поставил блокировку: он ждёт, он получает старое значение или он получает ошибку?
В драйвере для php нет pconnect(persistent connection)… А это значит каждая вновь запущенная php'шка будет задерживаться на открытии соединения от нескольким миллисекунд до 3 с лишним секунд. 3 секунды нужны для ожидания Syn пакета, который отправляется не ранее 3 секунд. Это происходит в моменты когда нагрузка на сервер внезапно возрастает по каким либо причинам и вместо того чтобы работать php'шки будут подвисать на коннекте к gibson на 3 сек, что недопустимо. Можно конечно через pfsockopen попробовать, но вот умеет ли gibson это?
Еще не плохо бы в мультигет запросах заиметь некий метаязык который бы позволил в одном запросе в случае хита получить ещё что-то с ключом зависимым от значения полученного ранее. Например записываешь список пользователей и при записи указываешь список зависимых ключей, а когда получаешь список из N пользователей и если такой список есть, сразу выдать ещё N значений с атрибутами пользователей. Экономия сотен микросекунд.
Уважаемые китайцы сделайте уже китайский Android Phone, Планшет и всё остальное с беспроводной зарядкой и сделайте кучу беспроводных зарядок для стола, стены, автомобильный держатель с зарядкой и т.д… Жду! :-)
И ещё вопрос. А у Вас на мастере и слейве в shared memory одинаковые таблички и индексы или На мастере одна группа таблиц, а на слейве другая? Это к вопросу эффективности использования оперативной памяти на мастере и слэйве…
shared memory было 4Гб, стало аж 12Гб. + дисковый кэш увеличился до ~30-32Гб против 8Гб до переезда…
если поставите pgbouncer и ограничите пул до ~20-24 то сможете ещё shared memory увелить смело до 40Гб… Обычно pgbouncer используют для снижения нагрузки на винт, но у Вас сейчас нагрузка ушла в процы. пул в 20-24 уменьшит кол-во переключений контектов у процессов postgres и недаст засвописться: 24*64Мб + (иногда 512Мб) + мелочи всякие = ~3Гб. поэтому 35Гб под shared можно, а это наверно ~50% базы в памяти.
Прирост конечно просто колоссальный судя по графикам… Но хочется как то оценить саму разницу между 9.0 и 9.2 в плане производительности, ведь разработчики заявляют что 9.2 стал в 2 раза быстрее, а кое в чём и в 5 раз…
Приведите пожалуйста характеристики серверов до переезда(оператива, диски, процы) и не плохо бы конфиги postgres(сколько shared memory, сколько под работу) и pgbouncer(сколько пул) чтобы примерно уложить в голове какая часть приплюснутой производительности появилась от flashcache, какая от postgres 9.2…
Автор просто смешал с грязью ipv6.
В статье речь идёт, как я понял, во всех случаях о попытках попользоваться ipv6 при его отсутствии. По всей видимости речь идёт о ip6to4, а не о ipv6.
У каждого туннельного провайдера свои особенности, наверное стоило разобраться в проблемах и их решить, а не просто включать/выключать.
Да и не стоит использовать ipv6to4 без острой необходимости. Туннель всегда хуже работает.
Для туннелей стоит урезать mtu, т.к. при обилии пакетов могут быть потери, а пакет о недоставке не пролезет в туннель и всё захлебнётся. Иногда нужно ограничить скорость удерживая в очереди пакеты на своём роутере чтобы избежать потерь пакетов. И т.д. и т.п.
Это не проблема ipv6, а нежелание копнуть поглубже.
Провайдеры проблемы в своих сетях начнут решать только при массовом использовании. Сегодня в России у топ провайдеров особых проблем не наблюдается. Только несуразные маршруты.
Из моих наблюдений в период COVID-19, по ipv4 трафик в Европу с трудом прорывается, а ipv6 стабильно работает. Возможно связано с иными путями и более новым оборудованием.
Если кнопка называется "Спам", то она должна отправлять в спам. Если называется "Отписаться", то она должна именно отписывать, а не то что mail.ru захотелось. Что написано, то и должно делаться. Не нужно никого вводить в заблуждение.
Mail.Ru при нажатии на отписаться делать 2 действия сразу: стучит по ссылке в заголовке List-Unsubscribe и шлёт ARF письмо на адрес указанный в настройках FeedLoop Back. Зачем?!
Я думаю если например репутация больше 1.0, то не показывать кнопку "Отписаться" вообще.
Если "Отписаться" возвращает код 4xx,5xx HTTP/SMTP в >10% процентах случаях, то скрыть кнопку "Отписаться".
Если большой процент пользователей кнопку "Отписаться" жмут в новых письмах присланных после предыдущего нажатия, тоже не показывать.
В "Спам" же отправлять только те что пользователь посчитал спамом, т.е. нажал кнопку "Спам".
Примерно такая политика должна отсеять недобросовестных рассыльщиков.
Скорее всего сейчас работает так как работает потому что реализуется за пару минут, а чтобы работало как надо нужно проделать большой объём работы. Будем надеяться что в mail.ru найдут время и все сделают.
на текущий момент pg_rewind также не перематывает если postgres остановлен аварийно. полтора года назад тоже ничего не мешало сделать так чтобы аварийно упавший postgres был остановлен штатно.
никакого ограничения здесь нет.
порядок действий таков.
1. выдергиваем мастер из розетки
2. переводим слейв в мастер
3. старый мастер втыкаем в розетку
4. запускаем старый мастер, он делает recovery
5. останавливаем старый мастер корректно
6. делаем на старом мастере recovery.conf
7. запускаем pg_rewind и он успешно перематывает
8. запускаем старый мастер(он же новый слейв) и он накатывает изменения с нового мастера
нужно иметь инструмент дающий максимально приближённые настройки, от которых уже отталкиваться, а не гадать на кофейной гуще. pgtune действительно тот инструмент который должен пригодиться даже бывалому.
комментарий действительно упустил. сейчас значения для текущего набора входных данных соответствуют. не хватает исходных данных, не плохо бы ещё оттолкнуться от тех параметров что я описал ранее.
Что касается checkpoint. простым языком checkpointer process непрерывно монотонно пишет изменённые страницы на диск пока не достигнет checkpoint_timeout или размера wal 16Мб. пишет на диск он те страницы которые не используются(вероятно не используются) чтобы не блокировать процесс выполнения запросов воркерами. все изменённые страницы обязательно должны быть записаны на диск, т.е. если воркеру нужна страница которой нет в разделяемой памяти(shared_buffers), то она берётся с диска и записывается в свободное место разделяемой памяти, а при отсутствии места вытесняет другую не изменённую(или уже записанную chekpointer process на диск). Если в shared_buffers все страницы изменены, то воркерам придётся подождать(для многих систем как правило ждать недопустимо) пока checkpointer process что-нибудь запишет на диск. Чем больше shared_buffers, тем меньше вероятность того что придётся ждать checkpointer process. Вообще если wal'ы пишутся на другие диске, то checkpointer process пишет почти в реальном времени на достаточно большой скорости без iowait. Объём данных которые пишет на диск checkpointer process зависит только от кол-ва данных которые были изменены запросами типа insert, update и т.д., но никак не от размера shared_buffers.
Цитата из рассылки это из области «Люди говорят». Но когда пытаешься найти таких людей чтобы с ними это обсудить лично, то никак их найти не получается. Как правило в рассылке обсуждается один конкретный случай, на конкретном железе и конкретном ПО(кроме postgres там ещё php, java, python и т. д.) на этой же машине. Во всех 4х пунктам в Вашей цитате есть доля правды, но это конкретный случай.
В документации нигде нет информации о 8 Гб. Не понятно почему вы привязали калькулятор PgTune к этому значению и навязываете людям. Калькулятор должен учесть все основные факторы и выдать приближенные значения для конкретного случая который описал человек заполняя поля в форме PgTune. А Вы во всех случаях банально выдаёте заведомо не правильное единственное значение 8 Гб. Чтобы правильно настроить postgres нужно абсолютно чётко понимать как он это делает. Объясните, пожалуйста, как postgres это делает и почему с 8 Гб он это сделает лучше чем с 600 Гб. Наверняка я в чём то заблуждаюсь, откройте мне глаза, объясните на понятном русском как есть на самом деле без ссылок на фразы где так же нет объяснения.
В калькуляторе нужно учитывать как минимум наличие пулера, максимальное кол-во воркеров, объём оперативной памяти, производительность дисков, объём памяти требуемое другому ПО.
в любом случае всё нужно записать на диск, а запись зависит от кол-ва insert, update, delete и т.д., но ни как не от объёма shared_buffers. более того, чем больше shared_buffers тем меньше вероятность того что диск будет задействован на чтение, а значит меньше iowait для записи на диск.
а ещё в shared memory можно посмотреть какие данные там лежат, чего нельзя сделать в дисковом кэше. www.postgresql.org/docs/9.3/static/pgbuffercache.html. это позволяет разработчику оценить и написать запросы так чтобы более эффективно использовать оперативную память, сократить обращения к диску. а если имеется несколько слэйв серверов, то можно на одном слэйве в памяти уложить одни данные, а на другом другие для эффективного использования памяти.
конечно с диска физически читаться не будет, будет браться с дискового кэша, но этот миксер создаст огромную нагрузку на процессоры. При 100Гб горячих данных и около 1000 запросов в сек вряд ли этот миксер справится даже на многопроцессорном серваке.
если дать 600Гб shared_buffers, то в памяти сразу будет эти 100Гб горячих и ещё 500Гб иногда используемых данных. не будет обращений в дисковую подсистему, не будет постоянных копирований данных из дискового кэша в shared_buffers
главное чтобы (shared_buffers + (максимальное кол-во postgres воркеров * work_mem) + запас) не превысили объём доступной оперативной памяти, иначе всё начнёт свопиться и будет segmentation fault… так же нужно учесть что на серваке кто-то ещё может использовать оперативную память, например php
включите логирование долгих запросов log_min_duration_statement. ставите как можно больше shared_buffers. затем берёте самые тяжёлые и смотрите план запросов… регулируйте work_mem так чтобы план для этих запросов становился наилучшим, pgadmin это покажет в графическом виде. учтите что слишком большие значения work_mem могут быть бесполезными, т. к. даже самому тяжелому запросу может много и не нужно. затем считаете сколько максимум shared_buffers можно поставить чтобы не засвопилось и ставите это значение.
например цифры из реальной жизни. моя база весит 1 терабайт, из них горячих данных около 100 гигабайт. на сервере 768 Гб памяти. ваш калькулятор предлагает shared_buffers = 8GB. с такими настройками это мёртвый сервер. а вот если shared_buffers = 600GB, то всё теперь будет зависеть от процессоров, которых кстати тоже вечно не хватает.
для новичков конечно и так сойдёт, но этот калькулятор на самом деле пустышка и будет вводить новичков заблуждение и развивает лень читать официальную документацию.
Вообще с ховерами там всё плохо, в разные моменты времени он работает по разному, то пропадает если ткнуть мимо, то всегда установлен и никак не снять…
Написал скриптик под opencv на c++ и использовал его из php. Просто выводит в консоль x, y, width и height
#include
#include
#include «opencv2/core/core.hpp»
#include «opencv2/features2d/features2d.hpp»
#include «opencv2/highgui/highgui.hpp»
#include «opencv2/calib3d/calib3d.hpp»
#include «opencv2/nonfree/features2d.hpp»
using namespace cv;
void readme();
/** function main */
int main( int argc, char** argv )
{
if( argc != 3 )
{ readme(); return -1; }
Mat img_object = imread( argv[1], CV_LOAD_IMAGE_GRAYSCALE );
Mat img_scene = imread( argv[2], CV_LOAD_IMAGE_GRAYSCALE );
if( !img_object.data || !img_scene.data )
{ std::cout max_dist ) max_dist = dist;
}
//-- Draw only «good» matches (i.e. whose distance is less than 3*min_dist )
std::vector good_matches;
for( int i = 0; i < descriptors_object.rows; i++ )
{ if( matches[i].distance < 3*min_dist )
{ good_matches.push_back( matches[i]); }
}
if (good_matches.size() == 0)
{
std::cout
В драйвере для php нет pconnect(persistent connection)… А это значит каждая вновь запущенная php'шка будет задерживаться на открытии соединения от нескольким миллисекунд до 3 с лишним секунд. 3 секунды нужны для ожидания Syn пакета, который отправляется не ранее 3 секунд. Это происходит в моменты когда нагрузка на сервер внезапно возрастает по каким либо причинам и вместо того чтобы работать php'шки будут подвисать на коннекте к gibson на 3 сек, что недопустимо. Можно конечно через pfsockopen попробовать, но вот умеет ли gibson это?
Еще не плохо бы в мультигет запросах заиметь некий метаязык который бы позволил в одном запросе в случае хита получить ещё что-то с ключом зависимым от значения полученного ранее. Например записываешь список пользователей и при записи указываешь список зависимых ключей, а когда получаешь список из N пользователей и если такой список есть, сразу выдать ещё N значений с атрибутами пользователей. Экономия сотен микросекунд.
:set nopaste
зы: главное перед вставкой отредактировать в иксах как надо
shared memory было 4Гб, стало аж 12Гб. + дисковый кэш увеличился до ~30-32Гб против 8Гб до переезда…
если поставите pgbouncer и ограничите пул до ~20-24 то сможете ещё shared memory увелить смело до 40Гб… Обычно pgbouncer используют для снижения нагрузки на винт, но у Вас сейчас нагрузка ушла в процы. пул в 20-24 уменьшит кол-во переключений контектов у процессов postgres и недаст засвописться: 24*64Мб + (иногда 512Мб) + мелочи всякие = ~3Гб. поэтому 35Гб под shared можно, а это наверно ~50% базы в памяти.
Приведите пожалуйста характеристики серверов до переезда(оператива, диски, процы) и не плохо бы конфиги postgres(сколько shared memory, сколько под работу) и pgbouncer(сколько пул) чтобы примерно уложить в голове какая часть приплюснутой производительности появилась от flashcache, какая от postgres 9.2…