IVB

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

Возможно мне кажется, но конфиг говорит об обратном: Ну я ведь там же отметил, что Более того, до этой минуты я был уверен, что у меня параметр innodb_flush_log_at_trx_commit равен именно 2-м... Спасибо, что обратили внимание. В своем конфиге очень часто не замечаешь своих ошибок :(

Я довольно много времени уделил настройкам мускуля. Именно под большие нагрузки. Но я сильно сомневаюсь, что добился максимального результата... Хотелось бы понять - стОит ли и дальше "вылизывать" настройки, или дешевле будет добавить 4-й винт и переразбить RAID5 в RAID10.

+-----------------------------------------+-------------------------------------------------------------------------------------------+ | Variable_name | Value | +-----------------------------------------+-------------------------------------------------------------------------------------------+ | auto_increment_increment | 1 | | auto_increment_offset | 1 | | autocommit | ON | | automatic_sp_privileges | ON | | back_log | 50 | | basedir | /usr/ | | big_tables | OFF | | binlog_cache_size | 32768 | | binlog_direct_non_transactional_updates | OFF | | binlog_format | ROW | | bulk_insert_buffer_size | 8388608 | | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results | utf8 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | | collation_connection | utf8_general_ci | | collation_database | utf8_general_ci | | collation_server | utf8_general_ci | | completion_type | 0 | | concurrent_insert | 2 | | connect_timeout | 10 | | datadir | /var/mysql/ | | date_format | %Y-%m-%d | | datetime_format | %Y-%m-%d %H:%i:%s | | default_week_format | 0 | | delay_key_write | ON | | delayed_insert_limit | 100 | | delayed_insert_timeout | 300 | | delayed_queue_size | 1000 | | div_precision_increment | 4 | | engine_condition_pushdown | ON | | error_count | 0 | | event_scheduler | OFF | | expire_logs_days | 7 | | flush | OFF | | flush_time | 0 | | foreign_key_checks | ON | | ft_boolean_syntax | + -><()~*:""&| | | ft_max_word_len | 84 | | ft_min_word_len | 4 | | ft_query_expansion_limit | 20 | | ft_stopword_file | (built-in) | | general_log | OFF | | general_log_file | /var/run/mysqld/mysqld.log | | group_concat_max_len | 1024 | | have_community_features | NO | | have_compress | YES | | have_crypt | YES | | have_csv | YES | | have_dynamic_loading | YES | | have_geometry | YES | | have_innodb | YES | | have_ndbcluster | NO | | have_openssl | DISABLED | | have_partitioning | NO | | have_query_cache | YES | | have_rtree_keys | YES | | have_ssl | DISABLED | | have_symlink | YES | | hostname | mysqls | | identity | 0 | | ignore_builtin_innodb | OFF | | init_connect | | | init_file | | | init_slave | | | innodb_adaptive_hash_index | ON | | innodb_additional_mem_pool_size | 6291456 | | innodb_autoextend_increment | 8 | | innodb_autoinc_lock_mode | 1 | | innodb_buffer_pool_size | 262144000 | | innodb_checksums | ON | | innodb_commit_concurrency | 0 | | innodb_concurrency_tickets | 500 | | innodb_data_file_path | ibdata1:10M:autoextend:max:512M | | innodb_data_home_dir | | | innodb_doublewrite | ON | | innodb_fast_shutdown | 1 | | innodb_file_io_threads | 4 | | innodb_file_per_table | ON | | innodb_flush_log_at_trx_commit | 1 | | innodb_flush_method | | | innodb_force_recovery | 0 | | innodb_lock_wait_timeout | 50 | | innodb_locks_unsafe_for_binlog | OFF | | innodb_log_buffer_size | 8388608 | | innodb_log_file_size | 52428800 | | innodb_log_files_in_group | 2 | | innodb_log_group_home_dir | ./ | | innodb_max_dirty_pages_pct | 90 | | innodb_max_purge_lag | 0 | | innodb_mirrored_log_groups | 1 | | innodb_open_files | 300 | | innodb_rollback_on_timeout | OFF | | innodb_stats_method | nulls_equal | | innodb_stats_on_metadata | ON | | innodb_support_xa | ON | | innodb_sync_spin_loops | 20 | | innodb_table_locks | ON | | innodb_thread_concurrency | 10 | | innodb_thread_sleep_delay | 10000 | | innodb_use_legacy_cardinality_algorithm | ON | | insert_id | 0 | | interactive_timeout | 604800 | | join_buffer_size | 4194304 | | keep_files_on_create | OFF | | key_buffer_size | 1073741824 | | key_cache_age_threshold | 300 | | key_cache_block_size | 1024 | | key_cache_division_limit | 100 | | language | /usr/share/mysql/english/ | | large_files_support | ON | | large_page_size | 0 | | large_pages | OFF | | last_insert_id | 0 | | lc_time_names | en_US | | license | GPL | | local_infile | ON | | locked_in_memory | OFF | | log | OFF | | log_bin | ON | | log_bin_trust_function_creators | ON | | log_bin_trust_routine_creators | ON | | log_error | /var/log/mysql/mysqld.err | | log_output | FILE | | log_queries_not_using_indexes | ON | | log_slave_updates | OFF | | log_slow_queries | OFF | | log_warnings | 1 | | long_query_time | 10.000000 | | low_priority_updates | ON | | lower_case_file_system | OFF | | lower_case_table_names | 0 | | max_allowed_packet | 134217728 | | max_binlog_cache_size | 18446744073709547520 | | max_binlog_size | 1073741824 | | max_connect_errors | 10 | | max_connections | 1000 | | max_delayed_threads | 20 | | max_error_count | 64 | | max_heap_table_size | 67108864 | | max_insert_delayed_threads | 20 | | max_join_size | 18446744073709551615 | | max_length_for_sort_data | 1024 | | max_long_data_size | 134217728 | | max_prepared_stmt_count | 16382 | | max_relay_log_size | 0 | | max_seeks_for_key | 18446744073709551615 | | max_sort_length | 1024 | | max_sp_recursion_depth | 0 | | max_tmp_tables | 32 | | max_user_connections | 0 | | max_write_lock_count | 18446744073709551615 | | min_examined_row_limit | 0 | | multi_range_count | 256 | | myisam_data_pointer_size | 6 | | myisam_max_sort_file_size | 5368709120 | | myisam_mmap_size | 18446744073709551615 | | myisam_recover_options | OFF | | myisam_repair_threads | 1 | | myisam_sort_buffer_size | 31457280 | | myisam_stats_method | nulls_unequal | | myisam_use_mmap | OFF | | net_buffer_length | 8192 | | net_read_timeout | 30 | | net_retry_count | 10 | | net_write_timeout | 60 | | new | OFF | | old | OFF | | old_alter_table | OFF | | old_passwords | OFF | | open_files_limit | 9202 | | optimizer_prune_level | 1 | | optimizer_search_depth | 62 | | optimizer_switch | index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on | | pid_file | /var/run/mysqld/mysqld.pid | | plugin_dir | /usr/lib64/mysql/plugin | | port | 3306 | | preload_buffer_size | 32768 | | protocol_version | 10 | | pseudo_thread_id | 4069742 | | query_alloc_block_size | 8192 | | query_cache_limit | 67108864 | | query_cache_min_res_unit | 4096 | | query_cache_size | 536870912 | | query_cache_type | ON | | query_cache_wlock_invalidate | OFF | | query_prealloc_size | 8192 | | rand_seed1 | | | rand_seed2 | | | range_alloc_block_size | 4096 | | read_buffer_size | 524288 | | read_only | OFF | | read_rnd_buffer_size | 1048576 | | relay_log | | | relay_log_index | | | relay_log_info_file | relay-log.info | | relay_log_purge | ON | | relay_log_space_limit | 0 | | report_host | | | report_password | | | report_port | 3306 | | report_user | | | rpl_recovery_rank | 0 | | secure_auth | OFF | | secure_file_priv | | | server_id | 99 | | skip_external_locking | ON | | skip_name_resolve | ON | | skip_networking | OFF | | skip_show_database | OFF | | slave_compressed_protocol | OFF | | slave_exec_mode | STRICT | | slave_load_tmpdir | /tmp/ | | slave_net_timeout | 3600 | | slave_skip_errors | OFF | | slave_transaction_retries | 10 | | slow_launch_time | 2 | | slow_query_log | OFF | | slow_query_log_file | /var/run/mysqld/mysqld-slow.log | | socket | /var/run/mysqld/mysqld.sock | | sort_buffer_size | 1048576 | | sql_auto_is_null | ON | | sql_big_selects | ON | | sql_big_tables | OFF | | sql_buffer_result | OFF | | sql_log_bin | ON | | sql_log_off | OFF | | sql_log_update | ON | | sql_low_priority_updates | ON | | sql_max_join_size | 18446744073709551615 | | sql_mode | STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION | | sql_notes | ON | | sql_quote_show_create | ON | | sql_safe_updates | OFF | | sql_select_limit | 18446744073709551615 | | sql_slave_skip_counter | | | sql_warnings | OFF | | ssl_ca | | | ssl_capath | | | ssl_cert | | | ssl_cipher | | | ssl_key | | | storage_engine | MyISAM | | sync_binlog | 0 | | sync_frm | ON | | system_time_zone | EEST | | table_definition_cache | 256 | | table_lock_wait_timeout | 50 | | table_open_cache | 4096 | | table_type | MyISAM | | thread_cache_size | 38 | | thread_handling | one-thread-per-connection | | thread_stack | 262144 | | time_format | %H:%i:%s | | time_zone | SYSTEM | | timed_mutexes | OFF | | timestamp | 1368432405 | | tmp_table_size | 268435456 | | tmpdir | /tmp/ | | transaction_alloc_block_size | 8192 | | transaction_prealloc_size | 4096 | | tx_isolation | REPEATABLE-READ | | unique_checks | ON | | updatable_views_with_limit | YES | | version | 5.1.61-log | | version_comment | Gentoo Linux mysql-5.1.61 | | version_compile_machine | x86_64 | | version_compile_os | pc-linux-gnu | | wait_timeout | 604800 | | warning_count | 0 | +-----------------------------------------+-------------------------------------------------------------------------------------------+

Доброго времени суток. Нужен профессиональный совет. Есть самосборный сервер: - мать MSI 990FXA-GD65 - проц AMD FX™-6100 (3.3GHz) - память DDR3 4x8Gb 667MHz - диски 3 x WD4500HLHX (SATAIII, 10000rpm, 450Gb) В качестве ОС установлен Gentoo Linux x64 с ядром 3.2.1 Диски объединены в программный RAID5 общей емкостью 900Gb Назначение сервера - выделенный MySQL сервер. На сегодняшний день на сервере расположены следующие базы данных: - биллинг (самописный) - биллинг (UserSide) - форум (VBulletin 3.x) - 2 самописных системы мониторинга (друг друга не дублируют) + несколько "легких" БД, которыми можно пренебречь. Даже при такой нагрузке периодически возникают моменты, когда приложения, обращающиеся в БД, "подтормаживают". Когда же я поставил на этот же сервер pgsql и попытался развернуть из бэкапа БД zabbix (раньше эта БД располагалась на другом сервере) - практически все запросы к БД MySQL "замерзли". Решили не заморачиваться с pgsql и запустить zabbix с "чистой" БД MySQL (на этом же выделенном MySQL сервере). Однако запуск zabbix-сервера привел к довольно серьезным тормозам других приложений, работающих с БД (естественно, сам zabbix-сервер находится на другом сервере). В итоге БД zabbix вынесли на другой сервер, а передо мной встал вопрос: чем же вызван тот предел производительности, который мы имеем на сегодняшний день. Исходя из того, что запуск pgsql на этом же сервере "затормозил" работу MySQL - дело не в неоптимальных настройках той или другой БД. Я пока "грешу" на программный RAID5 - но это чисто субъективное ощущение, т.к. я не вижу, чтобы процессор был загружен даже в те моменты, когда в БД "затор" из запросов. Как и чем можно определить, в чем же узкое место вышеописанного сервера?

Я нашел здесь же, на НАГе, тему, в которой можно попросить софт...

Господа, у меня очень нескромный вопрос: где можно взять последнюю (3.8.5) версию ПО для SCE2020? scos-v385-b967-sce2000-classic-k9.pkg sca-bb-v385-b53.zip sca-bb-v385-b53-agents.zip sca-bb-v385-pp33-b23.zip sca-reporter-v385-b53.exe sca-reporter-v385-b53-cmd-linux.tgz scms-cm-v385-b14-unbundled-solaris-linux.tar scms-sm-v385-b90-leg.tgz scms-sm-v385-b90-rhl-64.tgz scms-sm-v385-b90-rhl.tgz scms-sm-v385-b90-sol.tgz InsightReporter-3.4.0_rhel5-x86-32bit.zip InsightReporter-3.4.0_rhel5-x86-64bit.zip

неужели я непонятно словами расписал? или вы хотите реальную схему посмотреть? так она намного сложнее, не вижу смысла тратить время (свое и тех, кто захочет помочь) на ее описание. да, наверное, так тоже должно заработать. для клиента на входе каждой сессии вешаем разные set community, а для аплинков запрещаем комьюнити не из "своей" сессии.

Наверняка крупные операторы сталкивались с такой задачей. Есть клиент: AS65535. Есть два аплинка: AS65531 и AS65532. С клиентом подняты две bgp сессии (в разных vlan'ах - 4001 и 4002). В обоих сессиях клиент анонсирует одну и ту же сетку. Требуется: отдавать анонсы клиента 65535 аплинку 65531 только тогда, когда поднята сессия в vlan 4001, отдавать анонсы клиента 65535 аплинку 65532 только тогда, когда поднята сессия в vlan 4002. Другими словами: если подняты обе сессии - отдаем анонсы обоим аплинкам. Если какая-то из сессий остановлена - перестаем отдавать анонсы соответствующему аплинку. На моей стороне один bgp сервер с одним AS65530, выполняющий функции сервера маршрутизации (т.е. только bgp - реальный маршрутизатор стоит рядом и получает с сервера маршрутизации готвую таблицу маршрутов). Первое, что приходит в голову - сделать на моей стороне второй RS, сессии с аплинками 65531 и 65532 поднимать с разных RS, сессии с клиентом поднимать по одной с каждого RS (т.е. vlan4001 - RS1, vlan4002 - RS2) - тогда анонсы клиента каждому из аплинков будут идти только при поднятой сессии в нужном vlan'е. Но мне такое решение кажется излишне громоздким. Можно ли поставленную задачу решить в рамках одного RS?

если он нужен везде - стоит пересмотреть архитектуру всей сети, или переложить L3 на более умные железки (ASR1k/9k например) если нужен не везде - повырубать на лишних интерфейсах, и свести его присутствие до минимума. Вы, наверное, не заметили мой сегодняшний пост от 07:35. У меня на всех интерфейсах, где arp proxy не нужен, он выключен. А нужен он всего на одном vlan'е...

2554 IP ARP entries, with 21 of them incomplete Это в 9 утра, при этом "ARP Input" кушает 13%. При максимальной нагрузке точную цифру не вспомню - но точно меньше 5000.

Разницы практически нет. У нас на всех IP интерфейсах стоит "no ip proxy-arp".

Уточнение: SP загружен примерно на 30%, его загрузка не меняется при изменениях загрузки RP. А с RP картина грустная. В "нормальном" режиме процесс "ARP Input" кушает примерно 30% (что, на мой взгляд, тоже очень много!), а в критические моменты (когда Циска перестает отвечать) процесс "ARP Input" начинает отжирать 90-95%%, при этом общая загрузка становится 99%/2% (т.е. даже на прерывания не остается ресурсов). Что самое непонятное - понаблюдали за бродкастом - нет интерфейсов, на которых было бы чрезмерное количество броадкастных пакетов (ни входящих, ни исходящих). Через 3 часа после "clear counters" самое большое количество броадкастных пакетов не превысило 3000. Т.е. мы пока не можем понять, чем занят процесс "ARP Input"...

Я ведь писал, что не хочу разбираться с линками. Если у меня пропадает MAC даунлинка, а у аплинка он не пропадает - где-то что-то криво настроено. И за поиски этих кривых настроек мне денег не платят. Поэтому меня вполне устроит, если flood трафик (т.е. трафик с неизвестным МАС-адресом получаетеля) будет просто дропаться. Т.е. предложенный вариант с ограничением flood rate - это именно то, что мне нужно. interfaces 1/49 flood unknown-unicast rate mbps 1

DST MAC у этого трафика какой - unicast или broadcast? Unicast. А в arp кэше его нет, может он там статиком прописан. show arp Как раз из кеша он и пропадает. У аплинка в кеше он еще есть (или он там вообще статиком прописан), поэтому аплинк гонит этот трафик на меня. А у меня этого MACа уже нет - поэтому моя железка не знает, куда его девать. Заниматься настройкой аплинка и даунлинка (для которых я являюсь транзитером) нет ни малейшего желания. Вопрос остался без ответа, поэтому повторю: Что происходит, если ingress flood трафик превышает заданный rate? Этот трафик дропается, или порт переводится в error-disabled? (в доке это очень невнятно описано)

Прочитал доку - так и не понял, что произойдет, когда flood превысит заданный порог. Не получится ли так, что флудящий порт просто будет отрублен? Попытался выставить значение 0 - не поддерживается. Пришлось ставить значение 1 mbps. Нет, порт-маппинг не используется. Речь идет о транзитном L2 трафике.

Можно увеличить время жизни MAC. Можно попытаться "разобраться" с аплинком - почему у него не экспайрится МАС (тогда он перестанет "пихать" мне трафик). Можно найти и устранить причину пропадания МАСа у даунлинка. Но все это - за пределами зоны моей ответственности. Поэтому я хочу решить проблему кардинально - дропать L2 трафик, у которого нет адресата. Чтобы проблемы моих линков не мешали жить мне. Как говорится, проблемы индейцев шерифа не волнуют.

DST MAC у этого трафика какой - unicast или broadcast? Unicast.

День добрый. Есть проблема. На OS6850 при определенном стечении обстоятельств по одному из vlan'ов заходит трафик (по L2), предназначенный для неизвестного MAC-адреса (т.е. раньше этот MAC был, теперь пропал). И OS6850 весь этот трафик начинает пихать во все порты этого vlan'а, в надежде, что где-то все-таки нужный MAC "найдется". Что, в свою очередь, создает проблемы для тех устройств, которые тоже находятся в этом vlan'е и не в состоянии нормально дропнуть этот паразитный трафик (грубо говоря - захлебываются). Вопрос: можно ли "отучить" OS6850 от такого поведения, и сделать так, чтобы весь L2 трафик для неизвестных MAC-адресов молча дропался. > show system System: Description: Alcatel-Lucent OS6850-P48X 6.4.4.551.R01 Service Release, August 28, 2012.,

Доброго времени суток всем. Что-то у меня не получается как следует разобраться с ACL на OS6850. Задача простая: мне нужно разрешить доступ к свичу по SSH с определенных сеток, и запретить со всех остальных. При этом транзитный трафик не должен затрагиваться. Меня устроит и другое решение задачи - поднять SSH только на одном интерфейсе (на "сером", который наружу вообще не будет виден).

Как я и предполагал - я сам и накосячил. В мультикастном vlan'е серверу был присвоен IP адрес, совпадающий с IPадресом 2-го стримера. Пакеты с остальных стримеров принимались нормально, а со 2-го - видимо, дропались кернелом. Срочно пора в отпуск :(

Порты Циски исключены - переткнул стримеры (201-й - в порт 202-го, а 202-й - в порт 201-го), ситуация не изменилась - поток с 202-го стримера где-то дропается...

Провел еще один эксперимент. На 1-м стримере на один канал повесил IP 230.1.202.7, на 2-м стримере на один из каналов повесил IP 230.1.201.7. Поток с 1-го стримера все равно принимается нормально, со 2-го - не принимается. Т.е. от адреса, на который идет вещание, поведение не зависит. Зависит только от стримера. Или от порта, которым стример подключен. Сравнил настройки 1-го и 2-го стримеров - отличий нет. Версии прошивок совпадают (железки одинаковые - PBI4000). Настройки портов, которыми стримеры подключены к Циске, тоже совпадают. Полтергейст какой-то...

А я на Вас так надеялся ;) Один стример - одна сетка. Так проще - и настраивать, и следить потом. По IP видно, с какого стримера поток. 201 - тикают. 202 - нет :( Этот момент я проверил одним из первых. Поток (в tcpdump) появляется с запуском утилиты dumprtp и прекращается с ее завершением. "Чужой" поток на интерфейс сервера подаваться не должен (и не подается).

Столкнулся с очередной проблемой - и опять встал в тупик. Наверняка опять где-то сам же и накосячил - но в упор не вижу, где. Есть несколько стримеров (возьмем для простоты два). Каждый стример вещает по 6 потоков. 1-й стример вещает с адреса 192.168.150.201, второй - 192.168.150.202. 1-й стример вещает потоки с адресами 230.1.201.* (* - от 1 до 6), второй - 230.1.202.* (* - от 1 до 6). Все стримеры вещают с порта 2002 на порт 5004. Клиенты все эти потоки видят без проблем. На том же сервере, на котором я настраиваю TV-архив, потоки с первого стримера пишутся нормально, со второго - не пишутся. tcpdump'ом я вижу потоки с обоих стримеров, заходящие на сервер. на файрволе есть разрешающее правило для мультикастных потоков: # iptables -L INPUT -n -v --line-numbers Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination (несущественные правила пропускаем) 12 0 0 ACCEPT udp -- vlan8 * 0.0.0.0/0 224.0.0.0/4 Счетчики файрвола сбрасываю перед каждым экспериментом. Запускаю dumprtp на поток с 1-го стримера - поток пишется, счетчики в 12-м правиле растут с соответствующей скоростью. Запускаю dumprtp на поток (любой из шести - эффект одинаков) со 2-го стримера - поток не пишется, счетчики остаются 0-ми, при этом tсpdump'ом я вижу этот поток в vlan8 (т.е. на сервер он заходит). OK. Если пакеты потока не попадают на правило файрвола - значит, они дропаются вышестоящим правилом. Добавляю 1-м правилом правило, разрешающее весь трафик (вообще весь, на любом интерфейсе). Счетчики на этом правиле медленно увеличиваются (я-то тоже по сети на сервере сижу), но поток со 2-го стримера даже в это правило явно не попадает. Трафик dumprtp в файл не пишется (естественно, т.к. этот трафик где-то дропается). В системе нет других таблиц, кроме filter (т.е. никаких PREROUTING в nat/mangle не существует). 1-е правило в INPUT разрешает весь трафик. Но поток со 2-го стримера где-то дропается (но я его вижу tcpdump'ом в правильном vlan'е). В логах ничего подозрительного. Где могут дропаться пакеты со второго стримера? (сервер тот же, что и в 1-м посте)