2016-05-02 20:44:37,965 WARN [xxxx.utils.ExceptionUtils] >>>------------> GOT SQLException.: 08S01:0:Read timed out
2016-05-02 20:44:40,245 WARN [xxxx.utils.ExceptionUtils] Got recoverable SQLException.
2016-05-02 20:44:40,284 WARN [xxxx.utils.ExceptionUtils] >>>------------> GOT SQLException.: null:0:The connection is closed.
2016-05-02 20:44:46,033 INFO [.xxxx.db.SQLText] getRelatedException code=0, null, messa=The connection is closed.
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The connection is closed.
at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(SQLServerException.java:190)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.checkClosed(SQLServerConnection.java:389)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.setAutoCommit(SQLServerConnection.java:1884)
at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.checkTransaction(BaseWrapperManagedConnection.java:529)
at org.jboss.resource.adapter.jdbc.WrappedConnection.checkTransaction(WrappedConnection.java:826)
at org.jboss.resource.adapter.jdbc.WrappedConnection.getMetaData(WrappedConnection.java:527)
На той же машине Express Edition нормально справляется.
Из дефолтных настроек в обоих инстансах менял только Maximum Server Memory: 5Gb.
Я понимаю что скорее всего это не совсем правильное место чтобы задавать такие вопросы, но чат закрыт на https://blogs.technet.microsoft.com/dataplatforminsider/2016/03/31/microsoft-sql-server-developer-edition-is-now-free/
Так что вдруг кто-то что-то знает или сталкивался с чем-то подобным. Или посоветуйте куда обратиться, plz.
Подскажите plz, у меня в тестах нагрузки MSSQL 2014 SP1 Developer Edition падает через какое-то время. Коннекшены просто рвутся.
А тот же Express Edition на той же машине на том же тестом вполне себе нормально справляется с нагрузкой.
Это скрытое ограничение Developer Edition? Как-то витиевато написано на сайте MS.
SQL Server 2012 Developer Edition – редакция позволяет разработчикам создавать приложения любого типа на базе SQL Server. Она включает все функциональные возможности выпуска Enterprise Edition, однако лицензируется как система для разработки и тестирования, а не для применения в качестве рабочего сервера.
Я мечтаю о работодателе, который требовал бы от меня неск. часов в неделю уделять своему IT проекту. Наверняка кроме Гугла есть еще такие компании. Положительный эффект очевиден как для работодателя, так так и для работника.
Браво, ztxn. Замечательное приведение к type=range. Добавил вам плюсик.
Но все же суть статьи была не в этом. Попробую пояснить.
Для большого числа видов запросов, определяемых пользователями, и в большинстве своем сложных и несводимых к type=range, для больших и широких таблиц, в свое время было выяснено, что одни и те же запросы (с точностью до автоматического перевода) вполне нормально работают на PostgreSQL/MS SQL Server (порт на Oracle сейчас готовится, и пока что показывает себя вполне пристойно), но начинают крайне медленно выполняться и сильно нагружать систему на MySQL, при наличии одних и тех же индексов.
Стоит отметить, что изначально система писалась именно под MySQL, и порты на другие базы данных зачастую не так оптимальны в силу необходимости перевода «нестандартных возможностей» MySQL.
С другой стороны, в защиту MySQL стоит сказать что остальная работа системы (читай обычные запросы) на MySQL выполняются либо так же быстро, либо гораздо быстрее чем на PostgreSQL/MS SQL Server.
В свете выявленной проблемы, и отсутствии возможности отказаться от MySQL, был разработан алгоритм, работающий только для MySQL, выявляющий покрывающие запрос индексы, информирующий оптимизатор MySQL об их наличии, или администратора системы об их отсутствии. Именно этот реально работающий, и решающий такую проблему с MySQL, алгоритм и был описан в статье.
Почему только покрывающий индекс, а не перевод условия в ДНФ, накопление статистики по данным столбцов, разбиение порядка и так далее, по списку того что было продемонстрировано выше, и многое другое? Другими словами почему не написать оптимизатор оптимизатора MySQL? Ответ, я думаю, очевиден.
Таким образом, видимо стоит добавить в задание, условие «допустим запросы не сводимы к type=range»
Относительно сортировки. Если покрывающий индекс не начинается со столбцов используемых в клозе order by, то нам грозит using filesort, который приводит к самым серьезным нагрузкам системы. Поэтому это условие первое.
> какой тип у нас имеет поле D, текст это, чар или варчар?
Так как сортировки по D в примере нет, то все три толстых строковых типа ведут себя одинаково.
> Какие значения принимает.
Безусловно ограничений на количество значений нет. На мой взгляд самоочевидно то, что что при наличии ограничений на количество значений в строковом типе в таблицах с миллионами записей, использование char/varchar/text не эффективно. Для таких случаев следует использовать статический (ENUM) или динамический (отдельная таблица) классификатор. И то и другое сводят толстое поле к тонкому и в таблице и в индексе.
> В своё время был удивлён, когда узнал, что like работает достаточно быстро при выборках типа like 'any%'.
Только при наличии b-tree индекса.
> В своё время был удивлён, когда узнал, что чар на порядок быстрее варчара при поиске, т.к. выделяется определённое количество места в памяти под значение.
Только при отсутствии индекса, и при условии что в таблице нет полей с непостоянной длиной (varchar/text/etc).
> В настоящее время был удивлён, когда узнал, что уже не надо оптимизировать OR, что mysql это делает сама )
Не все так радужно. Для простых условий — делает. А если OR внутри сложной комбинации скобок — то может ошибаться.
Похоже уже пора рисовать десять заповедей оптимизатора (My)SQL.
Вот и мои пять копеек. В статью не включил, потому что объяснить такую черную магию не могу.
Если у вас гарантированный полный скан покрывающего индекса для запроса без order by, и у таблицы первичный ключ — автоинкрементное поле, то добавление этого поля в начало покрывающего индекса даст 15-20% улучшения скорости. (Да, в реальности это означает что автоинкрементное поле дважды присутствует в индексе — в начале и в конце).
Думается, оборот «обычных innodb/myisam» не совсем корректен. Эти два движка имеют столько различий, что с равным успехом можно было бы говорить об «обычных Oracle / MS SQL Server».
Percona XtraDB (Innodb-plugin) просто оптимизированный форк от InnoDB. Чего-то специфичного в оптимизации на уровне SQL запросов, отличающего его от InnoDB, мне не известно. С удовольствием узнаю что-то новое.
Относительно оптимизации запросов для MyISAM видимо нужна отдельная статья. Но я не большой специалист по MyISAM.
Похоже у нас завязалась настоящая дискуссия.
Я хотел бы попросить вас, уважаемый shagguboy, дочитывать приводимые ссылки до конца.
А далее там же написано что адаптивный хеш индекс строится только в памяти, только поверх существующего B-tree индекса, и только в тех случаях когда оптимайзер найдет это целесообразным. То есть в случае множества запросов с type=const/ew_ref
К сожалению такие случаи не попадают под изначальные условия статьи.
Microsoft SQL Server 2014 — 12.0.4213.0 (X64)
Jun 9 2015 12:06:16
Copyright © Microsoft Corporation
Developer Edition (64-bit) on Windows NT 6.3 (Build 9600: )
После получаса работы теста под нагрузкой просто рвет коннекшен: SQLException.: 08S01:0:Read timed out
Лог SQL сервера девственно чист. Лог приложения (Java):
2016-05-02 20:44:37,965 WARN [xxxx.utils.ExceptionUtils] >>>------------> GOT SQLException.: 08S01:0:Read timed out
2016-05-02 20:44:40,245 WARN [xxxx.utils.ExceptionUtils] Got recoverable SQLException.
2016-05-02 20:44:40,284 WARN [xxxx.utils.ExceptionUtils] >>>------------> GOT SQLException.: null:0:The connection is closed.
2016-05-02 20:44:46,033 INFO [.xxxx.db.SQLText] getRelatedException code=0, null, messa=The connection is closed.
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The connection is closed.
at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(SQLServerException.java:190)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.checkClosed(SQLServerConnection.java:389)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.setAutoCommit(SQLServerConnection.java:1884)
at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.checkTransaction(BaseWrapperManagedConnection.java:529)
at org.jboss.resource.adapter.jdbc.WrappedConnection.checkTransaction(WrappedConnection.java:826)
at org.jboss.resource.adapter.jdbc.WrappedConnection.getMetaData(WrappedConnection.java:527)
На той же машине Express Edition нормально справляется.
Microsoft SQL Server 2014 — 12.0.2269.0 (X64)
Jun 10 2015 03:35:45
Copyright © Microsoft Corporation
Express Edition (64-bit) on Windows NT 6.3 (Build 9600: )
Из дефолтных настроек в обоих инстансах менял только Maximum Server Memory: 5Gb.
Я понимаю что скорее всего это не совсем правильное место чтобы задавать такие вопросы, но чат закрыт на https://blogs.technet.microsoft.com/dataplatforminsider/2016/03/31/microsoft-sql-server-developer-edition-is-now-free/
Так что вдруг кто-то что-то знает или сталкивался с чем-то подобным. Или посоветуйте куда обратиться, plz.
А тот же Express Edition на той же машине на том же тестом вполне себе нормально справляется с нагрузкой.
Это скрытое ограничение Developer Edition? Как-то витиевато написано на сайте MS.
SQL Server 2012 Developer Edition – редакция позволяет разработчикам создавать приложения любого типа на базе SQL Server. Она включает все функциональные возможности выпуска Enterprise Edition, однако лицензируется как система для разработки и тестирования, а не для применения в качестве рабочего сервера.
Но все же суть статьи была не в этом. Попробую пояснить.
Для большого числа видов запросов, определяемых пользователями, и в большинстве своем сложных и несводимых к type=range, для больших и широких таблиц, в свое время было выяснено, что одни и те же запросы (с точностью до автоматического перевода) вполне нормально работают на PostgreSQL/MS SQL Server (порт на Oracle сейчас готовится, и пока что показывает себя вполне пристойно), но начинают крайне медленно выполняться и сильно нагружать систему на MySQL, при наличии одних и тех же индексов.
Стоит отметить, что изначально система писалась именно под MySQL, и порты на другие базы данных зачастую не так оптимальны в силу необходимости перевода «нестандартных возможностей» MySQL.
С другой стороны, в защиту MySQL стоит сказать что остальная работа системы (читай обычные запросы) на MySQL выполняются либо так же быстро, либо гораздо быстрее чем на PostgreSQL/MS SQL Server.
В свете выявленной проблемы, и отсутствии возможности отказаться от MySQL, был разработан алгоритм, работающий только для MySQL, выявляющий покрывающие запрос индексы, информирующий оптимизатор MySQL об их наличии, или администратора системы об их отсутствии. Именно этот реально работающий, и решающий такую проблему с MySQL, алгоритм и был описан в статье.
Почему только покрывающий индекс, а не перевод условия в ДНФ, накопление статистики по данным столбцов, разбиение порядка и так далее, по списку того что было продемонстрировано выше, и многое другое? Другими словами почему не написать оптимизатор оптимизатора MySQL? Ответ, я думаю, очевиден.
Таким образом, видимо стоит добавить в задание, условие «допустим запросы не сводимы к type=range»
Относительно сортировки. Если покрывающий индекс не начинается со столбцов используемых в клозе order by, то нам грозит using filesort, который приводит к самым серьезным нагрузкам системы. Поэтому это условие первое.
Так как сортировки по D в примере нет, то все три толстых строковых типа ведут себя одинаково.
> Какие значения принимает.
Безусловно ограничений на количество значений нет. На мой взгляд самоочевидно то, что что при наличии ограничений на количество значений в строковом типе в таблицах с миллионами записей, использование char/varchar/text не эффективно. Для таких случаев следует использовать статический (ENUM) или динамический (отдельная таблица) классификатор. И то и другое сводят толстое поле к тонкому и в таблице и в индексе.
> В своё время был удивлён, когда узнал, что like работает достаточно быстро при выборках типа like 'any%'.
Только при наличии b-tree индекса.
> В своё время был удивлён, когда узнал, что чар на порядок быстрее варчара при поиске, т.к. выделяется определённое количество места в памяти под значение.
Только при отсутствии индекса, и при условии что в таблице нет полей с непостоянной длиной (varchar/text/etc).
> В настоящее время был удивлён, когда узнал, что уже не надо оптимизировать OR, что mysql это делает сама )
Не все так радужно. Для простых условий — делает. А если OR внутри сложной комбинации скобок — то может ошибаться.
Похоже уже пора рисовать десять заповедей оптимизатора (My)SQL.
Вот и мои пять копеек. В статью не включил, потому что объяснить такую черную магию не могу.
Если у вас гарантированный полный скан покрывающего индекса для запроса без order by, и у таблицы первичный ключ — автоинкрементное поле, то добавление этого поля в начало покрывающего индекса даст 15-20% улучшения скорости. (Да, в реальности это означает что автоинкрементное поле дважды присутствует в индексе — в начале и в конце).
Percona XtraDB (Innodb-plugin) просто оптимизированный форк от InnoDB. Чего-то специфичного в оптимизации на уровне SQL запросов, отличающего его от InnoDB, мне не известно. С удовольствием узнаю что-то новое.
Относительно оптимизации запросов для MyISAM видимо нужна отдельная статья. Но я не большой специалист по MyISAM.
С уважением,
PAV.
Я хотел бы попросить вас, уважаемый shagguboy, дочитывать приводимые ссылки до конца.
А далее там же написано что адаптивный хеш индекс строится только в памяти, только поверх существующего B-tree индекса, и только в тех случаях когда оптимайзер найдет это целесообразным. То есть в случае множества запросов с type=const/ew_ref
К сожалению такие случаи не попадают под изначальные условия статьи.
Но чтобы закончить спор я переформулирую фразу.
С уважением,
PAV.
> Рассматривается движок MySQL innodb/percona — в дальнейшем просто MySQL.
Сейчас выделю.
По той же ссылке видим:
Storage Engine Permissible Index Types
MyISAM — BTREE
InnoDB — BTREE
MEMORY/HEAP — HASH, BTREE
NDB — HASH, BTREE (see note in text)
Фактически, вторичный ключ вида KEY `key` (a,b,c) будет иметь структуру KEY `key` (a,b,c,clustered_index).
С уважением,
PAV.
С уважением,
PAV.