Задать вопрос

Юрий

highload developer
Комментарии

  • Silverlight + WCF: настройки хостинга?

    @bRUtality Автор вопроса
    А как его почистить?
    Написано

  • В гугле забанили

    @bRUtality Автор вопроса
    Дело в том, что не открывается только google.ru
    Написано

  • В гугле забанили

    @bRUtality Автор вопроса
    Бинго! Без каспера заработало. Теперь осталось выяснить, что сделать, чтобы работало с каспером :) У меня KIS2013.
    Написано

  • В гугле забанили

    @bRUtality Автор вопроса
    Как то так.
    tracerout output
    Сервер pptp-l2tp-vpn-russia-1.atomintersoft.com

    Tracing route to google.ru [173.194.71.94]
    over a maximum of 20 hops:

    1 <1 ms <1 ms <1 ms 46.183.162.2
    2 2 ms 2 ms 1 ms v810.m9-3.caravan.ru [212.24.42.129]
    3 2 ms 2 ms 1 ms msk-ix-gw1.google.com [193.232.244.232]
    4 20 ms 25 ms 146 ms 72.14.236.248
    5 30 ms 48 ms 30 ms 209.85.243.138
    6 29 ms 33 ms 28 ms 72.14.233.172
    7 * * * Request timed out.
    8 28 ms 31 ms 30 ms lb-in-f94.1e100.net [173.194.71.94]

    Trace complete.

    Сервер pptp-l2tp-vpn-russia-3.atomintersoft.com

    Tracing route to google.ru [173.194.71.94]
    over a maximum of 20 hops:

    1 <1 ms <1 ms 1 ms 46.183.162.2
    2 2 ms 1 ms 1 ms v811.m9-3.caravan.ru [212.24.42.49]
    3 2 ms 1 ms 1 ms msk-ix-gw1.google.com [193.232.244.232]
    4 20 ms 25 ms 146 ms 72.14.236.248
    5 29 ms 32 ms 45 ms 209.85.249.40
    6 32 ms 30 ms 28 ms 72.14.233.170
    7 * * * Request timed out.
    8 28 ms 32 ms 29 ms lb-in-f94.1e100.net [173.194.71.94]

    Trace complete.

    Сервер openvpn-russia-6.atomintersoft.com
    traceroute to google.ru (173.194.71.94), 30 hops max, 40 byte packets
    1 46.183.162.2 (46.183.162.2) 1.090 ms 1.713 ms 1.998 ms
    2 v810.m9-3.caravan.ru (212.24.42.129) 2.660 ms v811.m9-3.caravan.ru (212.24.42.49) 2.650 ms 2.881 ms
    3 msk-ix-gw1.google.com (193.232.244.232) 3.596 ms 3.573 ms 3.557 ms
    4 209.85.240.102 (209.85.240.102) 22.300 ms 72.14.236.248 (72.14.236.248) 21.794 ms 209.85.240.102 (209.85.240.102) 21.783 ms
    5 209.85.249.40 (209.85.249.40) 30.502 ms 72.14.233.180 (72.14.233.180) 30.726 ms 209.85.243.136 (209.85.243.136) 30.470 ms
    6 72.14.233.170 (72.14.233.170) 30.458 ms 30.225 ms 72.14.233.168 (72.14.233.168) 27.978 ms
    7 lb-in-f94.1e100.net (173.194.71.94) 28.362 ms 29.036 ms 29.022 ms

    Сервер pptp-l2tp-vpn-sweden-1.atomintersoft.com
    Tracing route to google.ru [173.194.71.94]
    over a maximum of 20 hops:

    1 <1 ms <1 ms <1 ms gw.5.34.240.webexxpurts.com [5.34.240.1]
    2 <1 ms <1 ms <1 ms vl-362-turbovps.sto2.se.portlane.net [80.67.1.49]
    3 <1 ms <1 ms <1 ms te-2-2.sto3.se.portlane.net [80.67.4.136]
    4 <1 ms <1 ms <1 ms po12-20g.sto4.se.portlane.net [80.67.4.169]
    5 1 ms <1 ms <1 ms netnod-ix-ge-b-sth-1500.google.com [194.68.128.115]
    6 1 ms 1 ms 1 ms 216.239.43.248
    7 10 ms 9 ms 9 ms 209.85.243.136
    8 9 ms 9 ms 9 ms 72.14.233.172
    9 * * * Request timed out.
    10 10 ms 9 ms 9 ms lb-in-f94.1e100.net [173.194.71.94]

    Trace complete.

    Сервер pptp-vpn-uk-2.atomintersoft.com
    Tracing route to google.ru [173.194.67.94]
    over a maximum of 20 hops:

    1 <1 ms <1 ms <1 ms 213.246.181.193
    2 5 ms 5 ms 5 ms ia-hosting.com [213.246.152.198]
    3 5 ms 5 ms 5 ms Te1-5.core02.thd.uk.as8586.net [212.58.37.119]
    4 5 ms 5 ms 5 ms tg2-2.core04.thd.uk.as8586.net [212.58.37.124]
    5 5 ms 5 ms 5 ms google1.lonap.net [5.57.80.136]
    6 5 ms 5 ms 5 ms 209.85.255.76
    7 35 ms 33 ms 6 ms 209.85.253.196
    8 11 ms 11 ms 11 ms 66.249.95.173
    9 11 ms 11 ms 18 ms 209.85.250.161
    10 * * * Request timed out.
    11 11 ms 11 ms 11 ms wi-in-f94.1e100.net [173.194.67.94]

    Trace complete.

    Сервер pptp-vpn-usa-1.atomintersoft.com
    Tracing route to google.ru [74.125.140.94]
    over a maximum of 20 hops:

    1 2 ms <1 ms 1 ms gw.5.34.246.webexxpurts.com [5.34.246.1]
    2 <1 ms <1 ms <1 ms 66.219.27.29
    3 <1 ms <1 ms <1 ms 67.23.161.134
    4 6 ms 6 ms 6 ms 67.23.161.139
    5 7 ms 7 ms 7 ms xe-9-1-3.edge5.Atlanta2.Level3.net [4.71.254.77]
    6 7 ms 7 ms 7 ms ae-1-51.edge1.Atlanta4.Level3.net [4.69.150.15]
    7 8 ms 8 ms 7 ms GOOGLE-INC.edge1.Atlanta4.Level3.net [4.53.232.90]
    8 8 ms 8 ms 8 ms 72.14.233.56
    9 8 ms 8 ms 8 ms 66.249.94.20
    10 48 ms 8 ms 8 ms 209.85.248.57
    11 * * * Request timed out.
    12 8 ms 8 ms 8 ms ye-in-f94.1e100.net [74.125.140.94]

    Trace complete.

    Написано

  • В гугле забанили

    @bRUtality Автор вопроса
    Firefox нормально грузит страничку хоть с включенным, хоть с выключенным spdy. Кстати, по умолчанию spdy теперь включено, вроде раньше было наоборот.
    Написано

  • События файловой системы по ftp

    @bRUtality Автор вопроса
    Тогда он мне подошел бы, если существовала версия для работы в фоне под линуксом.
    Написано

  • События файловой системы по ftp

    @bRUtality Автор вопроса
    Признаться, не понял, как он работает. Если по таймауту лезет в удаленную папку и копирует, то я тоже так могу с помощью cron + скрипт_на_чем_угодно.
    Написано

  • События файловой системы по ftp

    @bRUtality Автор вопроса
    Если я правильно понял, это планировщик копирования по ftp, на события файловой системы он не реагирует. К тому же под линукс нет версии. Но все равно спасибо за участие.
    Написано

  • События файловой системы по ftp

    @bRUtality Автор вопроса
    В гугле не забанили, сюда я уже смотрел. Но эта штука серверо-исполняемая, как я понял.
    Написано

  • События файловой системы по ftp

    @bRUtality Автор вопроса
    К серверу, к сожалению, доступ не имею. Я тоже догадывался, что одним клиентом задачу не решить, но на всякий случай решил спросить.
    Написано

  • События файловой системы по ftp

    @bRUtality Автор вопроса
    Этот вариант, конечно же, первое, что приходит в голову. Но хотелось бы красивое решение.
    Написано

  • PostgreSQL. Индексы и партицирование

    @bRUtality Автор вопроса
    Пересечений по условию у меня нет (проверял: один и тот же запрос на партицию и на мастер-таблицу отработал за одно и то же время). Кстати, руководствовался этим же примером :)

    Ваш explain выдает «Index Scan», а мой «Seq Scan». Значит таблицу/индекс я создал все-таки как-то по другому. Спасибо, появилось, за что зацепиться — буду копать в этом направлении.
    Написано

  • PostgreSQL. Индексы и партицирование

    @bRUtality Автор вопроса
    Извиняюсь за долгий ответ — в праздники не было доступа к серверу.

    1) непартицированная:
    explain analyze (select * from cdr_data order by id desc limit 10);
    QUERY PLAN
    ---------------------------------------------------------------------------------------------------------------------------------------------------------
    Limit (cost=0.00..0.46 rows=10 width=418) (actual time=61.820..96.951 rows=10 loops=1)
    -> Index Scan Backward using cdr_data_pkey on cdr_data (cost=0.00..1268387.17 rows=27676900 width=418) (actual time=61.817..96.927 rows=10 loops=1)
    Total runtime: 96.992 ms
    (3 rows)


    2) партицированная:
    explain analyze (select * from cdr_data_master order by id desc limit 10);
    QUERY PLAN
    ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
    Limit (cost=1850530.19..1850530.21 rows=10 width=100) (actual time=278037.222..278037.245 rows=10 loops=1)
    -> Sort (cost=1850530.19..1966777.30 rows=46498846 width=100) (actual time=278037.218..278037.227 rows=10 loops=1)
    Sort Key: public.cdr_data_master.id
    Sort Method: top-N heapsort Memory: 26kB
    -> Result (cost=0.00..845706.84 rows=46498846 width=100) (actual time=14.359..213654.201 rows=46495464 loops=1)
    -> Append (cost=0.00..845706.84 rows=46498846 width=100) (actual time=14.357..132664.369 rows=46495464 loops=1)
    -> Seq Scan on cdr_data_master (cost=0.00..0.00 rows=1 width=532) (actual time=0.001..0.001 rows=0 loops=1)
    -> Seq Scan on cdr_data_100mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
    -> Seq Scan on cdr_data_105mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.000..0.000 rows=0 loops=1)
    -> Seq Scan on cdr_data_10mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.000..0.000 rows=0 loops=1)
    -> Seq Scan on cdr_data_110mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
    -> Seq Scan on cdr_data_115mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.000..0.000 rows=0 loops=1)
    -> Seq Scan on cdr_data_120mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
    -> Seq Scan on cdr_data_125mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
    -> Seq Scan on cdr_data_130mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
    -> Seq Scan on cdr_data_135mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
    -> Seq Scan on cdr_data_140mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
    -> Seq Scan on cdr_data_145mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.000..0.000 rows=0 loops=1)
    -> Seq Scan on cdr_data_150mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
    -> Seq Scan on cdr_data_155mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
    -> Seq Scan on cdr_data_15mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
    -> Seq Scan on cdr_data_160mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
    -> Seq Scan on cdr_data_165mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
    -> Seq Scan on cdr_data_170mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
    -> Seq Scan on cdr_data_175mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.000..0.000 rows=0 loops=1)
    -> Seq Scan on cdr_data_180mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
    -> Seq Scan on cdr_data_185mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.000..0.000 rows=0 loops=1)
    -> Seq Scan on cdr_data_190mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
    -> Seq Scan on cdr_data_195mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
    -> Seq Scan on cdr_data_200mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.000..0.000 rows=0 loops=1)
    -> Seq Scan on cdr_data_20mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
    -> Seq Scan on cdr_data_25mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.000..0.000 rows=0 loops=1)
    -> Seq Scan on cdr_data_30mln cdr_data_master (cost=0.00..35162.66 rows=1934658 width=100) (actual time=14.310..2524.045 rows=1934658 loops=1)
    -> Seq Scan on cdr_data_35mln cdr_data_master (cost=0.00..4475.61 rows=247612 width=100) (actual time=16.907..320.907 rows=247612 loops=1)
    -> Seq Scan on cdr_data_40mln cdr_data_master (cost=0.00..1949.81 rows=107813 width=100) (actual time=0.253..140.468 rows=107813 loops=1)
    -> Seq Scan on cdr_data_45mln cdr_data_master (cost=0.00..2940.79 rows=162790 width=101) (actual time=0.233..201.041 rows=162790 loops=1)
    -> Seq Scan on cdr_data_50mln cdr_data_master (cost=0.00..64148.52 rows=3532521 width=100) (actual time=0.260..4702.547 rows=3532521 loops=1)
    -> Seq Scan on cdr_data_55mln cdr_data_master (cost=0.00..90983.00 rows=5000000 width=100) (actual time=12.778..6816.170 rows=5000000 loops=1)
    -> Seq Scan on cdr_data_5mln cdr_data_master (cost=0.00..10.14 rows=140 width=532) (actual time=0.001..0.001 rows=0 loops=1)
    -> Seq Scan on cdr_data_60mln cdr_data_master (cost=0.00..90966.00 rows=5000000 width=100) (actual time=15.267..7191.117 rows=5000000 loops=1)
    -> Seq Scan on cdr_data_65mln cdr_data_master (cost=0.00..90745.99 rows=4999985 width=100) (actual time=0.006..4416.925 rows=5000000 loops=1)
    -> Seq Scan on cdr_data_70mln cdr_data_master (cost=0.00..90984.87 rows=4999873 width=100) (actual time=0.004..4479.866 rows=5000000 loops=1)
    -> Seq Scan on cdr_data_75mln cdr_data_master (cost=0.00..90957.88 rows=4999883 width=100) (actual time=21.760..7057.975 rows=5000000 loops=1)
    -> Seq Scan on cdr_data_80mln cdr_data_master (cost=0.00..90970.00 rows=5000000 width=99) (actual time=11.269..6761.104 rows=5000000 loops=1)
    -> Seq Scan on cdr_data_85mln cdr_data_master (cost=0.00..90950.00 rows=5000000 width=99) (actual time=11.657..6516.789 rows=5000000 loops=1)
    -> Seq Scan on cdr_data_90mln cdr_data_master (cost=0.00..90934.00 rows=5000000 width=99) (actual time=10.520..6740.251 rows=5000000 loops=1)
    -> Seq Scan on cdr_data_95mln cdr_data_master (cost=0.00..9274.07 rows=510070 width=99) (actual time=9.752..695.643 rows=510070 loops=1)
    Total runtime: 278037.660 ms
    (48 rows)

    Разницу только вижу в сортировке партиций :)
    Написано

  • PostgreSQL. Индексы и партицирование

    @bRUtality Автор вопроса
    1) Выполняется быстрее, но с Sec scan.
    2) Не совсем аналогичные. Есть таблица с индексом на колонке с датой, там все работает как нужно (т.е. сканятся именно партиции), и скорость выполнения запроса на порядки быстрее на партицированной таблице по сравнению с непартицированной.

    Обновление постараюсь накатить до конца рабочего дня.
    Написано

  • PostgreSQL. Индексы и партицирование

    @bRUtality Автор вопроса
    > Посмотрите еще, что будет c enable_seqscan=off. Может ему статистики не хватает на таблицах?
    Попробовал, не помогло.

    > Какая у Вас версия постгреса? archives.postgresql.org/pgsql-performance/2011-04/msg00385.php
    Вот это очень полезная информация! Версия у меня 9.0.4. Там очень похожая проблема: постгрес сканит sequence по всем партициям (судя по ауту explain analyze), но не сканит индекс. Пишут, что было пофиксено в 9.1. Попробую обновиться.
    Спасибо!
    Написано

  • PostgreSQL. Индексы и партицирование

    @bRUtality Автор вопроса
    >Я всётаки не спец по таким вещам, но попробуйте проверить включены-ли индексы.
    >ALTER TABLE cdr_data_100mln ENABLE TRIGGER cdr_data_100mln_pkey;

    Прошу прощения, здесь какой триггер имеется ввиду? На insert у меня триггер есть. На select, если я правильно понимаю механизм партицирования, триггер не нужен, а нужно создать индекс по полю, по которому партицируем.
    Написано

  • PostgreSQL. Индексы и партицирование

    @bRUtality Автор вопроса
    1)
    SHOW constraint_exclusion;
    constraint_exclusion
    ----------------------
    on

    Это обязательно, т.к. на этом сервере у меня уже есть один хайлоад :)

    2)
    Страно, но на непартицированной таблице запрос отработал немного быстрее (38 сек против 50)

    explain analyze (select * from cdr_data where id>20000000 and id<30000000);
    QUERY PLAN
    ------------------------------------------------------------------------------------------------------------------------------------------
    Bitmap Heap Scan on cdr_data (cost=3703.24..214997.03 rows=138384 width=418) (actual time=9416.847..31960.503 rows=8040678 loops=1)
    Recheck Cond: ((id > 20000000) AND (id < 30000000))
    -> Bitmap Index Scan on cdr_data_pkey (cost=0.00..3668.65 rows=138384 width=0) (actual time=9368.697..9368.697 rows=8040678 loops=1)
    Index Cond: ((id > 20000000) AND (id < 30000000))
    Total runtime: 38382.290 ms
    (5 rows)

    explain analyze (select * from cdr_data_master where id>60000000 and id<70000000);
    QUERY PLAN
    ----------------------------------------------------------------------------------------------------------------------------------------------------------
    Result (cost=0.00..231735.26 rows=10000001 width=100) (actual time=0.014..43035.965 rows=9999999 loops=1)
    -> Append (cost=0.00..231735.26 rows=10000001 width=100) (actual time=0.012..25708.944 rows=9999999 loops=1)
    -> Index Scan using cdr_data_master_pkey on cdr_data_master (cost=0.00..4.26 rows=1 width=532) (actual time=0.005..0.005 rows=0 loops=1)
    Index Cond: ((id > 60000000) AND (id < 70000000))
    -> Seq Scan on cdr_data_65mln cdr_data_master (cost=0.00..115746.00 rows=5000000 width=100) (actual time=0.005..4875.700 rows=4999999 loops=1)
    Filter: ((id > 60000000) AND (id < 70000000))
    -> Seq Scan on cdr_data_70mln cdr_data_master (cost=0.00..115985.00 rows=5000000 width=100) (actual time=0.010..4975.571 rows=5000000 loops=1)
    Filter: ((id > 60000000) AND (id < 70000000))
    Total runtime: 50992.342 ms
    (9 rows)

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

  • PostgreSQL. Индексы и партицирование

    @bRUtality Автор вопроса
    Либо лыжи не едут, либо я…

    Вот скрин мастер-таблицы:
    image


    С потомка:
    image
    Написано

  • Посоветуйте онлайн багтрекер

    @bRUtality Автор вопроса
    В том-то и дело, что работаем каждый из дома:( но все равно спасибо за совет.
    Написано

  • Посоветуйте онлайн багтрекер

    @bRUtality Автор вопроса
    По крайней мере, оригинально:)
    Написано