Добро пожаловать в сообщество AggreGate
вопросы, касающиеся управления серверами, масштабирования оборудования, устранения проблем запуска/работы программ, использование памяти/процессора и т.д.
andyray06/rambler_ru » Чт сен 01, 2016 2:17 pm
Здравствуйте.
Спустя некоторое время после запуска сервера AG начинает наблюдаться снижение производительности. Выражается это, в частности, в более длительном времени реакции на запросы от клиентов и задержках в обработке сигналов от подключенных устройств.
Если во время снижения производительности прочитать информацию о состоянии сервера, то можно заметить что параметр "Длина очереди событий" (eventQueueLength) достигает довольно высоких значений, в то время как сразу после перезагрузки он был равен 0. Использование памяти находится где-то в пределах 40-70%
Можете посоветовать, каким образом можно определить, что именно является "узким местом"?
-
andyray06/rambler_ru
-
- Сообщения: 33
- Зарегистрирован: Ср авг 05, 2015 6:12 am
-
anton_logoyskiy/tibbo_com » Ср сен 07, 2016 5:08 am
Андрей, добрый день!
Судя по Вашему описанию, есть проблема с БД. Какую БД вы используете? Размещена ли она на другом физическом сервере? Я обратил бы внимание на настройки работы AggreGate с базой данных и со стороны БД проверил производительность выполнения запросов AggreGate.
С уважением, Антон Логойский Tibbo Systems
-
anton_logoyskiy/tibbo_com
-
- Сообщения: 93
- Зарегистрирован: Ср июл 22, 2015 10:05 am
-
andyray06/rambler_ru » Ср сен 07, 2016 7:01 am
Здравствуйте, Антон. Используем MySQL 5.7. БД и AggreGate установлены на одном физическом сервере, но устанавливались раздельно. Конфигурация MySQL следующая: - Код: Выделить всё
[client] no-beep
port=3306
[mysql]
default-character-set=utf8
[mysqld]
port=3306
datadir=C:/ProgramData/MySQL/MySQL Server 5.7\Data
character-set-server=utf8
default-storage-engine=INNODB
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
log-output=FILE general-log=0 general_log_file="DIGLETT.log" slow-query-log=1 slow_query_log_file="DIGLETT-slow.log" long_query_time=10
log-error="DIGLETT.err"
server-id=1
secure-file-priv="C:/ProgramData/MySQL/MySQL Server 5.7/Uploads"
skip-external-locking max_connections=1000
query_cache_size = 100M
table_open_cache=2000
tmp_table_size=527M
thread_cache_size = 32
myisam_max_sort_file_size=100G
myisam_sort_buffer_size=2G
key_buffer_size = 384M
read_buffer_size=64K read_rnd_buffer_size=256K
innodb_flush_log_at_trx_commit = 0
innodb_log_buffer_size = 8M
innodb_buffer_pool_size = 2G
innodb_log_file_size = 500M
innodb_thread_concurrency=13
innodb_autoextend_increment=64
innodb_buffer_pool_instances=8
innodb_concurrency_tickets=5000
innodb_old_blocks_time=1000
innodb_open_files=300
innodb_stats_on_metadata=0
innodb_file_per_table=1
innodb_checksum_algorithm=0
back_log=80
flush_time=0
join_buffer_size=256K
max_allowed_packet = 256M
max_connect_errors=100
open_files_limit=4161
query_cache_type=0
sort_buffer_size=256K
table_definition_cache=1400
binlog_row_event_max_size=8K
sync_master_info=10000
sync_relay_log=10000
sync_relay_log_info=10000
plugin_load="mysqlx"
loose_mysqlx_port=33060 innodb_lock_wait_timeout = 1200
Настройки AggreGate:

- AggreGate Config.PNG (116.75 КБ) Просмотров: 34598
Подскажите, как можно проверить производительность выполнения запросов на стороне СУБД? В логах MySQL есть подобные записи: InnoDB: page_cleaner: 1000ms intended loop took 4618ms. The settings might not be optimal.
-
andyray06/rambler_ru
-
- Сообщения: 33
- Зарегистрирован: Ср авг 05, 2015 6:12 am
-
andyray06/rambler_ru » Пт сен 09, 2016 8:03 am
В дополнение к возможным проблемам с NoSQL. При удалении контекста устройства, в логах появляются следующие записи: - Код: Выделить всё
09.09.2016 11:59:27,532 ERROR org.apache.cassandra.db.filter.SliceQueryFilter Scanned over 100000 tombstones in aggregate.ag_change; query aborted (see tombstone_failure_threshold) - [ReadStage:27] org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns (SliceQueryFilter.java:206) 09.09.2016 11:59:27,534 ERROR org.apache.cassandra.service.CassandraDaemon Exception in thread Thread[ReadStage:27,5,main] - [ReadStage:27] org.apache.cassandra.service.CassandraDaemon$2.uncaughtException (CassandraDaemon.java:199) java.lang.RuntimeException: org.apache.cassandra.db.filter.TombstoneOverwhelmingException at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2008) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: org.apache.cassandra.db.filter.TombstoneOverwhelmingException at org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:208) at org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:122) at org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:80) at org.apache.cassandra.db.RowIteratorFactory$2.getReduced(RowIteratorFactory.java:101) at org.apache.cassandra.db.RowIteratorFactory$2.getReduced(RowIteratorFactory.java:75) at org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:115) at org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:98) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at org.apache.cassandra.db.ColumnFamilyStore$9.computeNext(ColumnFamilyStore.java:1597) at org.apache.cassandra.db.ColumnFamilyStore$9.computeNext(ColumnFamilyStore.java:1593) at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) at org.apache.cassandra.db.ColumnFamilyStore.filter(ColumnFamilyStore.java:1756) at org.apache.cassandra.db.ColumnFamilyStore.getRangeSlice(ColumnFamilyStore.java:1714) at org.apache.cassandra.db.RangeSliceCommand.executeLocally(RangeSliceCommand.java:137) at org.apache.cassandra.service.StorageProxy$LocalRangeSliceRunnable.runMayThrow(StorageProxy.java:1461) at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2004) ... 3 more 09.09.2016 11:59:37,272 WARN ag.context.events Error removing persistent events from context 'opcua' - [Action / Удалить] com.tibbo.linkserver.context.BaseServerContext.destroy (BaseServerContext.java:770) java.lang.RuntimeException: com.netflix.astyanax.connectionpool.exceptions.OperationTimeoutException: OperationTimeoutException: [host=10.0.250.219(10.0.250.219):9160, latency=10036(10036), attempts=1]TimedOutException() at com.netflix.astyanax.thrift.ThriftAllRowsQueryImpl.getNextBlock(ThriftAllRowsQueryImpl.java:105) at com.netflix.astyanax.thrift.ThriftAllRowsImpl$1.hasNext(ThriftAllRowsImpl.java:96) at com.tibbo.linkserver.plugin.persistence.nosql.cassandra.EmbeddedCassandraService.removeEvents(EmbeddedCassandraService.java:381) at com.tibbo.linkserver.plugin.persistence.nosql.NoSqlEventDao.deleteEvents(NoSqlEventDao.java:421) at com.tibbo.linkserver.plugin.persistence.nosql.NoSqlEventDao.deleteEvents(NoSqlEventDao.java:386) at com.tibbo.linkserver.context.BaseServerContext.destroy(BaseServerContext.java:766) at com.tibbo.linkserver.device.DefaultDeviceContext.destroy(DefaultDeviceContext.java:696) at com.tibbo.aggregate.common.context.AbstractContext.destroyChild(AbstractContext.java:1316) at com.tibbo.linkserver.context.EditableChildrenContext.destroyChild(EditableChildrenContext.java:492) at com.tibbo.linkserver.context.EditableChildrenContext.callFdelete(EditableChildrenContext.java:539) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.tibbo.aggregate.common.context.AbstractContext.executeImplementationMethod(AbstractContext.java:3009) at com.tibbo.aggregate.common.context.AbstractContext.executeImplementation(AbstractContext.java:2949) at com.tibbo.aggregate.common.context.AbstractContext.callFunction(AbstractContext.java:2894) at com.tibbo.aggregate.common.context.AbstractContext.callFunction(AbstractContext.java:3042) at com.tibbo.aggregate.common.context.AbstractContext.callFunction(AbstractContext.java:3048) at com.tibbo.linkserver.action.CallFunctionAction$CallFunctionActionImpl.execute(CallFunctionAction.java:292) at com.tibbo.linkserver.action.CallFunctionAction$CallFunctionActionImpl.execute(CallFunctionAction.java:236) at com.tibbo.aggregate.common.action.SingleThreadAction$ActionThread.run(SingleThreadAction.java:261) Caused by: com.netflix.astyanax.connectionpool.exceptions.OperationTimeoutException: OperationTimeoutException: [host=10.0.250.219(10.0.250.219):9160, latency=10036(10036), attempts=1]TimedOutException() at com.netflix.astyanax.thrift.ThriftConverter.ToConnectionPoolException(ThriftConverter.java:171) at com.netflix.astyanax.thrift.AbstractOperationImpl.execute(AbstractOperationImpl.java:65) at com.netflix.astyanax.thrift.AbstractOperationImpl.execute(AbstractOperationImpl.java:28) at com.netflix.astyanax.thrift.ThriftSyncConnectionFactoryImpl$ThriftConnection.execute(ThriftSyncConnectionFactoryImpl.java:153) at com.netflix.astyanax.connectionpool.impl.AbstractExecuteWithFailoverImpl.tryOperation(AbstractExecuteWithFailoverImpl.java:119) at com.netflix.astyanax.connectionpool.impl.AbstractHostPartitionConnectionPool.executeWithFailover(AbstractHostPartitionConnectionPool.java:352) at com.netflix.astyanax.thrift.ThriftAllRowsQueryImpl.getNextBlock(ThriftAllRowsQueryImpl.java:73) ... 21 more Caused by: TimedOutException() at org.apache.cassandra.thrift.Cassandra$get_range_slices_result$get_range_slices_resultStandardScheme.read(Cassandra.java:17448) at org.apache.cassandra.thrift.Cassandra$get_range_slices_result$get_range_slices_resultStandardScheme.read(Cassandra.java:17397) at org.apache.cassandra.thrift.Cassandra$get_range_slices_result.read(Cassandra.java:17323) at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78) at org.apache.cassandra.thrift.Cassandra$Client.recv_get_range_slices(Cassandra.java:802) at org.apache.cassandra.thrift.Cassandra$Client.get_range_slices(Cassandra.java:786) at com.netflix.astyanax.thrift.ThriftAllRowsQueryImpl$1.internalExecute(ThriftAllRowsQueryImpl.java:81) at com.netflix.astyanax.thrift.ThriftAllRowsQueryImpl$1.internalExecute(ThriftAllRowsQueryImpl.java:76) at com.netflix.astyanax.thrift.AbstractOperationImpl.execute(AbstractOperationImpl.java:60) ... 26 more
-
andyray06/rambler_ru
-
- Сообщения: 33
- Зарегистрирован: Ср авг 05, 2015 6:12 am
-
andyray06/rambler_ru » Вт сен 27, 2016 6:40 am
Антон, здравствуйте! Есть какие-нибудь новости по исправлениям? Ссылки не видел ни в PM, ни на почте. Пробовали перевести хранилище событий на MySQL, проблема с недоступностью истории событий разрешилась, но с производительностью все так же. В целом, отмечаются проблемы следующего плана: Спустя некоторое время после перезагрузки сервера заканчивается HEAP, что вызывает постоянное срабатывание gc со всеми вытекающими. Под HEAP на данный момент выделено 20 Гб. vmoptions следующие, если интересно:
- Код: Выделить всё
-server -Xms20480m -Xmx20480m -Xss512k -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:-OmitStackTraceInFastThrow -Duser.language=ru -Dswing.systemlaf=javax.swing.plaf.nimbus.NimbusLookAndFeel
-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -XX:+ScavengeBeforeFullGC -XX:+CMSScavengeBeforeRemark -XX:+CMSParallelRemarkEnabled -XX:+UseParNewGC -XX:NewRatio=3 -XX:SurvivorRatio=4
В ином случае все как описано в первом посте, загрузка памяти где-то на уровне 60% и постоянный рост показателя длины очереди событий. Своими силами довольно сложно как-то подробнее диагностировать в чем проблема, то-ли дело в конфигурации "проекта", то-ли в настройках JVM, СУБД и т.д. Буду признателен, если подскажете способ для более точной диагностики.
-
andyray06/rambler_ru
-
- Сообщения: 33
- Зарегистрирован: Ср авг 05, 2015 6:12 am
-
andyray06/rambler_ru » Ср сен 28, 2016 4:17 am
Обновили версию сервера AG до 5.31.05, проблема с бесконечным ростом очереди событий осталась. Проявляется спустя несколько часов (около 12-16 если быть точнее) после перезагрузки сервера.
-
andyray06/rambler_ru
-
- Сообщения: 33
- Зарегистрирован: Ср авг 05, 2015 6:12 am
-
Вернуться в Системное администрирование
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1
|