kapow_expert: насколько я помню это ведь тоже апача проект? может ошибаюсь...
Совсем нет. И в этом его преимущество.
попробовать можно. а данные именно такие и нужны. можно правда повыкидывать лишнее. по сути мне нужен айди телефона, время, и 2 координаты. Кстати тут еще ньюанс. я использую постгре с постгисом - координаты преобразую в геометрии и сую в базу.
Ну так просто нагенерите в табличку сотню миллионов рандомных записей, и проверьте.
Я смутно представляю себе, как работает постгис, но что-то мне подсказывает, что это плевая задача - учитывая всякие openstreetmaps.org.
У меня данные приходят в гет запросе, где двоеточием разделены столбцы (координата Х, координата У, высота, скорость, время). Пхп скрипт делает split и сразу инсерт.
Координаты в виде дробных градусов? ID записи имеется?
Но вобщем, в любом случае - время выполнения - копеечное.
86 миллионов в сутки. а хотелось бы хотя бы месяц хранить.
Ну, во-первых, у вас данные жестко структурированые, и незначительного объема - я бы на вашем месте сначала на кошках потренировался, есть неплохая вероятность, что пару-тройку млрд. строк база переварит, и не чихнет.
Во-вторых, вам действительно жизненно необходимо хранить сырые необработанные данные? Это может быть нелучшим вариантом.
Outsourcenow добавил 03.12.2009 в 19:51
myhand: это весьма спорно. наоборот, если логики в постобработке скриптом мало - можно и засунуть ее в модуль апача, например. + mpm worker использовать.
Идея скрещивать веб-сервер с sql - порочна в принципе.
Но вцелом, если так уж хочется - проще дописать плагин к nginx, как, собственно, многие и делают. Только от sql в качестве хранилища надо будет отказаться совершенно точно.
Первым делом настроить апач, поставить на него такие то модули. Разнести его на 4 сервера - 2 ведущих и 3 слэйва. Базу раскинуть на еще 3 сервера такой то мощности с такими то райдами.
Первым делом нужно выкинуть апач вообще.
Вторым делом нужно корректно спроектировать прием данных - очевидно, что узким местом системы будет именно бесконтрольно плодящиеся потоки php-процессов. Сделовательно, первый шаг оптимизации - сокращение времени на прием и сохранение данных. Минимум обработки, и максимально быстрое засовывание в хранилище - причем, не обязательно БД, вполне может быть и memcachedb, в котором организована очередь.
Впрочем, 60к в минуту - это всего 1к в сек., mysql вполне сносно умеет порядка 6-8 тыс. инсертов в секунду.
Также хотелось бы пообщаться со специалистом по базам данных, который умеет горизонтально разносить данные. Путем несложного расчета можно определить что вышеописанная система пишет в базу 86 миллионов строк данных, храня которые в 1 таблице выборки по ней уже будет невозможно делать.
Выборки по таблице в 200 млн строк при грамотно написаных индексах у меня на десктопе занимают порядка 2-3 сек.
Но если вы напрягаетесь по этому поводу - откройте для себя шардинг.
netwind: Никуда они не исчезнут. Можно время сократить через sysctl net.ipv4.tcp_fin_timeout
Вот во freebsd есть sysctl net.inet.tcp.fast_finwait2_recycle, это поинтересней.
FIN_WAIT от TIME_WAIT немножко так отличаются :-)
Кроме того, в линуксовом ip-стеке по-дефолту работает nolocaltimewait, если мне не изменяет память.
ps/2: Во фре вообще говоря есть net.inet.tcp.msl :-) А REUSE у сокетов работает во всех операционных системах, достаточно, чтобы у инициатора tcp-сессии в опциях сокета этот флаг стоял.
если бы вы знали работу правил то увидили, что те что построены, на лимитах, это не блокировка Ip.иди-ТЕ маны читайте...прежде чем в ввязывать в разговор серьёзный.:)
Вы как-то совсем не хотите понять, что вам Химик пытается донести - а он совершенно прав.
Принимать решение порезать трафик на основе подсчета пакетиков-сессий - ума большого не надо. Давайте, чтобы было понятно, на конкретных примерах - с вашего сервера дергают /index.php 400 раз в секунду. Постоянно с разных ip-адресов. Корреляции между временем запроса и ip-адресом нет, распределение - строго равномерное.
За минуту это будет 24000 хитов. Известно, что из них - 200 хитов валидные, все остальные - ддос.
И - да, 200 хитов - это, скажем, транзакции платежной системы, соответственно, продолбленные 200 запросов - стоят, условно, $10к.
Написать на языке С программу, которая будет открывать TCP/IP сокет, принимать на него данные и записывать их в память или файл.
Самая здравая идея, кстати. Минус ровно один - времени на отладку многопоточного самодельного демона уйдет - вагон.
насколько я помню это ведь тоже апача проект? может ошибаюсь...
Совсем нет. И в этом его преимущество.
попробовать можно. а данные именно такие и нужны. можно правда повыкидывать лишнее. по сути мне нужен айди телефона, время, и 2 координаты. Кстати тут еще ньюанс. я использую постгре с постгисом - координаты преобразую в геометрии и сую в базу.
Ну так просто нагенерите в табличку сотню миллионов рандомных записей, и проверьте.
Я смутно представляю себе, как работает постгис, но что-то мне подсказывает, что это плевая задача - учитывая всякие openstreetmaps.org.
П.с написал вам в асю.
Вылез, стукнтитесь еще раз, если не сложно.
а на что же его поменять? :)
nginx естественно.
У меня данные приходят в гет запросе, где двоеточием разделены столбцы (координата Х, координата У, высота, скорость, время). Пхп скрипт делает split и сразу инсерт.
Координаты в виде дробных градусов? ID записи имеется?
Но вобщем, в любом случае - время выполнения - копеечное.
86 миллионов в сутки. а хотелось бы хотя бы месяц хранить.
Ну, во-первых, у вас данные жестко структурированые, и незначительного объема - я бы на вашем месте сначала на кошках потренировался, есть неплохая вероятность, что пару-тройку млрд. строк база переварит, и не чихнет.
Во-вторых, вам действительно жизненно необходимо хранить сырые необработанные данные? Это может быть нелучшим вариантом.
Outsourcenow добавил 03.12.2009 в 19:51
это весьма спорно. наоборот, если логики в постобработке скриптом мало - можно и засунуть ее в модуль апача, например. + mpm worker использовать.
Идея скрещивать веб-сервер с sql - порочна в принципе.
Но вцелом, если так уж хочется - проще дописать плагин к nginx, как, собственно, многие и делают. Только от sql в качестве хранилища надо будет отказаться совершенно точно.
Открыть файл, и нажать "Сохранить в режиме UNIX" в вашем любимом текстовом редакторе.
Из консоли-то работает?
Поди, файлик в windows открывали/сохраняли? И \n\r в конце так кривые и остались.
Первым делом настроить апач, поставить на него такие то модули. Разнести его на 4 сервера - 2 ведущих и 3 слэйва. Базу раскинуть на еще 3 сервера такой то мощности с такими то райдами.
Первым делом нужно выкинуть апач вообще.
Вторым делом нужно корректно спроектировать прием данных - очевидно, что узким местом системы будет именно бесконтрольно плодящиеся потоки php-процессов. Сделовательно, первый шаг оптимизации - сокращение времени на прием и сохранение данных. Минимум обработки, и максимально быстрое засовывание в хранилище - причем, не обязательно БД, вполне может быть и memcachedb, в котором организована очередь.
Впрочем, 60к в минуту - это всего 1к в сек., mysql вполне сносно умеет порядка 6-8 тыс. инсертов в секунду.
Также хотелось бы пообщаться со специалистом по базам данных, который умеет горизонтально разносить данные. Путем несложного расчета можно определить что вышеописанная система пишет в базу 86 миллионов строк данных, храня которые в 1 таблице выборки по ней уже будет невозможно делать.
Выборки по таблице в 200 млн строк при грамотно написаных индексах у меня на десктопе занимают порядка 2-3 сек.
Но если вы напрягаетесь по этому поводу - откройте для себя шардинг.
ну вот что-то не работает это на другом сайте, где соединений побольше. Стало меньше,но не пропали совсем.
И не должны пропасть. Так и задумано.
Никуда они не исчезнут. Можно время сократить через sysctl net.ipv4.tcp_fin_timeout
Вот во freebsd есть sysctl net.inet.tcp.fast_finwait2_recycle, это поинтересней.
FIN_WAIT от TIME_WAIT немножко так отличаются :-)
Кроме того, в линуксовом ip-стеке по-дефолту работает nolocaltimewait, если мне не изменяет память.
ps/2: Во фре вообще говоря есть net.inet.tcp.msl :-) А REUSE у сокетов работает во всех операционных системах, достаточно, чтобы у инициатора tcp-сессии в опциях сокета этот флаг стоял.
1. Погуглите про TIME_WAIT
2. В обычной ситуации - не надо, в данном конкретном случае - стоит озаботится.
3. Если отказаться от уродской манеры проксировать запросы на внешний адрес, и перевесить апач на 127.0.0.1 - проблема скорее всего решится.
если бы вы знали работу правил то увидили, что те что построены, на лимитах, это не блокировка Ip.иди-ТЕ маны читайте...прежде чем в ввязывать в разговор серьёзный.:)
Вы как-то совсем не хотите понять, что вам Химик пытается донести - а он совершенно прав.
Принимать решение порезать трафик на основе подсчета пакетиков-сессий - ума большого не надо. Давайте, чтобы было понятно, на конкретных примерах - с вашего сервера дергают /index.php 400 раз в секунду. Постоянно с разных ip-адресов. Корреляции между временем запроса и ip-адресом нет, распределение - строго равномерное.
За минуту это будет 24000 хитов. Известно, что из них - 200 хитов валидные, все остальные - ддос.
И - да, 200 хитов - это, скажем, транзакции платежной системы, соответственно, продолбленные 200 запросов - стоят, условно, $10к.
Ваши действия?