У нас есть установка, которую мы используем для разных клиентов: программа, подключающаяся к серверу Firebird в локальной сети.
До сих пор мы в основном использовали 32-битные процессоры под управлением Ubuntu LTS (недавно обновленного до 10.04).
Теперь мы представили серверы на 64-битных процессорах под управлением 64-битной Ubuntu 10.04.
Внезапно некоторые запросы выполняются медленнее, чем раньше.
Вкратце: выполнение запроса локально отлично работает как на 64-битных, так и на 32-битных серверах, но при выполнении одних и тех же запросов по сети 64-битный сервер внезапно становится намного медленнее.
Мы провели несколько проверок как локальных, так и удаленных подключений к 64-битным и 32-битным серверам, используя идентичные базы данных и идентичные запросы, запущенные во Flamerobin.
Выполнение запроса локально занимает ничтожно мало времени: 0,008 с на 64-битном сервере, 0,014 с на 32-битном сервере. Так что сами серверы работают нормально.
При выполнении запросов по сети 64-битному серверу внезапно требуется 0,160 с для ответа, а 32-битный сервер отвечает за 0,055 с.
Таким образом, старые серверы в два раза быстрее работают по сети, хотя новые серверы в два раза быстрее, если они работают локально.
В остальном настройка идентична. На всех серверах установлена одна и та же установка Ubuntu 10.04, одна и та же версия Firebird и так далее, с той лишь разницей, что некоторые из них 64-битные, а некоторые 32-битные.
Любая идея??
Я пытался погуглить, но не смог найти никаких жалоб на то, что 64-разрядная версия Firebird медленнее 32-разрядной версии Firebird, за исключением того, что в журнале изменений Firebird 2.1 упоминается, что есть новый сетевой API, который работает в два раза быстрее, как только драйверы обновлены. использовать это.
Так что я мог представить, что 64-битный драйвер все еще использует старый API, но, думаю, это немного натянуто.
Заранее спасибо за любые ответы! :)
Убедитесь, что на старых и новых серверах
Проверить масштабирование окна на старых и новых серверах
Буфер чтения и записи для соединения
размер буферов может быть изменен по мере необходимости
root@x:~# sysctl -A | grep net | grep mem
Проверьте эти переменные
Они определяют максимальное использование буфера памяти по умолчанию для всех сетевых подключений в ядре.
net.core.wmem_max = 131071
net.core.rmem_max = 131071
net.core.wmem_default = 126976
net.core.rmem_default = 126976
Они определяют использование буферной памяти, специфичное для TCP-соединений.
net.ipv4.tcp_mem = 378528 504704 757056
net.ipv4.tcp_wmem = 4096 16384 4194304
net.ipv4.tcp_rmem = 4096 87380 4194304
Указанные три значения являются размерами буфера «минимальный максимальный размер по умолчанию». Итак, чтобы начать с linux, мы будем использовать значения по умолчанию для буфера чтения и записи для каждого соединения. По мере увеличения количества подключений эти буферы будут уменьшаться (максимум до указанного минимального значения). То же самое и с максимальным значением буфера.
Эти значения могут быть установлены с помощью этого sysctl -w KEY=KEY VALUE
Проверьте другие параметры сети TCP
Попробуйте эти
на старом сервере
sysctl -a | grep ^net.ipv4 >s1
на новом сервере
sysctl -a | grep ^net.ipv4 >s2
теперь сделайте diff файлов s1 и s2 (после копирования s2 на старый сервер
diff s1 s2
Это покажет разницу в параметрах
проверить статус iptables
iptables -L
iptables -t nat -L
на обоих серверах
Также проверьте статус selinux
другие сетевые транзакции медленны на 64-битных серверах? Это может быть что-то простое, например, плохой или устаревший сетевой драйвер.