Туннелирование в IPv6:
Я не гуру MySQL, и я не могу диагностировать проблему с этой информацией, но я пытался искать формулу в исходном коде.Вот:
server_buffers + total_per_thread_buffers * max_connections
Где:
server_buffers = key_buffer_size + innodb_buffer_pool_size + innodb_additional_mem_pool_size + innodb_log_buffer_size + query_cache_size
и:
total_per_thread_buffers = read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + join_buffer_size
Теперь необходимо проверить каждое из этих значений и фигуры, какой ответственен за это огромное количество. И не доверяйте этому сценарию полностью - я пытался выполнить его на одном из моих серверов БД, и он вычислил, что максимальная память составляет 140% общего объема физической памяти, но система работала в течение многих лет без любых проблем устойчивости.
Удачи!
6to4 обычный IP по туннелированию IP. Кто бы ни делает туннелирование, порождает пакеты. Начиная с Вашего Хоста A не имеет возможности соединения IPv4, это не может действовать как конечная точка туннеля.
Как пример, у меня есть маршрутизатор (R1) поле Linux с 6to4 маршрут, который смотрит таким образом:
2000::/3 через:: метрика 192.88.99.1 dev sit0 1 024 mtu 1480 advmss 1420 hoplimit 0
и IPv4 направляет таким образом:
значение по умолчанию через XXX.YYY.210.1 dev br0
Интернет трафик IPv6, входящий от LAN (например, от Хоста A), направляет к sit0. boxen на LAN полагает, что они непосредственно подключены к Интернету IPv6. Трафик от sit0 перенесен в пакеты IPv4 с R1 как исходный адрес и введен в br0, который соединяется с Интернетом IPv4.
Эти два маршрутизатора R1 и R2 сделают туннелирование. Пакеты, происходящие из R1, будут иметь заголовок IPv4 с адресом IPv4 R1 как источник, и адрес IPv4 R2 как место назначения (R1 отправляет к R2). Возвратитесь пакеты IPv4 будут иметь исходные адреса, и адреса назначения инвертировали (R2 отправляет к R1). Адреса IPv6 хостов A и B передадут непереведенный в заголовке инкапсулированного пакета. Обычно минимальный 20-байтовый заголовок IP4v используется, таким образом, MTU IPv6 (Максимальный Блок передачи) на туннеле будет самое большее 1 480 байтов.
Инкапсуляция просто состоит из добавления заголовка IPv4 к пакету IPv6 и маршрутизации его с помощью нормальной маршрутизации IPv6. Неинкапсуляция просто удаляет заголовок IPv4 и обычно направляет остающийся пакет IPv6. Для пакета IPv6 возможно быть переданным больше чем через один туннель между двумя хостами. Адреса IPv4 в IPv4 всегда будут адресом маршрутизатора с туннелированием (источник) и адрес маршрутизатора оконечной точки туннеля (место назначения).
Править: Следующее было записано для описания случая описанных в следующем параграфе. Другие абзацы предоставляют дополнительный фон.
HostA (IPv6) и HostB (IPv4) будет не мочь связаться, поскольку у них нет совместимых стеков. Если бы HostB имелся стек IPv6, то они могли бы связаться.
Хост двойного стека мог сделать свое собственное туннелирование, в этом случае его адрес IPv4 будет использоваться в качестве его адреса конечной точки IPv4. Если бы NAT используется затем, адрес его маршрутизатора был бы адресом конечной точки IPv4, в то время как пакет был в сети IPv4 между маршрутизаторами.
IPv6 не имеет NAT, таким образом, адреса IPv6 никогда не будут переводиться.
Поскольку IPv6 только размещает для общения с хостом IPv4, преобразование протоколов требуется. Хост A мог обратиться к Хосту B использование одной из схем IPv6 кодирования адресов IPv4 в IPv6. Маршрутизатор R1 должен был бы выполнить преобразование протоколов. (Хотя я не полагаю, что на рынке существуют любые такие маршрутизаторы.) Снова, адрес конечной точки IPv4 в сети IPv4 был бы адрес IPv4 R1. Некоторые сетевые возможности не могут быть переведены во время преобразования протоколов.