Нужна помощь - периодически лочится Mysql 5.5.34
Viacheslav Romanov
1) select * from users where userId = 222; 2) update users set name='dfdf' where userId = 333; 3) insert into users values (444, 'hello')
В аттаче вывод SHOW ENGINE INNODB STATUS и SHOW PROCESSLIST в момент двух последних дэдлоков
Konstantin Osipov
> именно лок, так как mysql работает всегда стабильно, с далекими от пиковых
> значений параметрами (loadavg и тд), а в момент лока запись на диск
> практически останавливается.
>
> В текущее время вся база (порядка 80GB) в памяти (inno_db_buffer_pool =
> 200G), и сервер только пишет на диски (~30-40 MB/sec в пиковое время).
>
> Все запросы примерно такие:
>
> 1) select * from users where userId = 222;
> 2) update users set name='dfdf' where userId = 333;
> 3) insert into users values (444, 'hello')
--
http://tarantool.org - an efficient, extensible in-memory data store
Viacheslav Romanov
Viacheslav Romanov
141011 14:23:38 [Warning] Aborted connection 630459 to db: 'unconnected' user: 'debian-sys-maint' host: 'localhost' (Got an error writing communication packets)
По времени иногда точно совпадает - это просто отваливается в этот момент все, или это из-за debian-sys-maint проблемы возможны?
Konstantin Osipov
> Не понял - что имеется в виду? В аттаче SHOW ENGINE INNODB STATUS\G
show status = это доп. информация.
Konstantin Osipov
> debian-sys-maint:
>
> 141011 14:23:38 [Warning] Aborted connection 630459 to db: 'unconnected'
> user: 'debian-sys-maint' host: 'localhost' (Got an error writing
> communication packets)
где-то лежит?
Viacheslav Romanov
Konstantin Osipov
Sveta Smirnova
On 10/13/2014 10:23 AM, Konstantin Osipov wrote:
> * Viacheslav Romanov<rvv...@gmail.com> [14/10/13 02:34]:
>> Не понял - что имеется в виду? В аттаче SHOW ENGINE INNODB STATUS\G
>
> show status = это доп. информация.
>
InnoDB само не выявляет и пользователь ошибок не получает. Или, строго
говоря, не о дедлоке вообще, а о длинном локе.
Вячеслав, я правильно понимаю, что выполнение транзакций "зависает" либо
на очень долгое время, либо до момента отключения клиента по timeout?
Включите ещё InnoDB lock monitor и повторите вывод SHOW ENGINE INNODB
STATUS: там будет информация о том, какие конкретно строки залочены.
Света.
Viacheslav Romanov
Database changed
mysql> CREATE TABLE innodb_monitor (a INT) ENGINE=INNODB;
Query OK, 0 rows affected (0.01 sec)
mysql> select version();
+-----------------------------+
| version() |
+-----------------------------+
| 5.5.38-0ubuntu0.14.04.1-log |
+-----------------------------+
1 row in set (0.00 sec)
Viacheslav Romanov
Sveta Smirnova
On 10/13/2014 07:00 PM, Viacheslav Romanov wrote:
Привет!
Да, речь видимо о длинном локе. Спасаюсь тем, что киляю все текущие процессы (иногда по несколько раз приходится).
Логирование CREATE TABLE innodb_monitor (a INT) ENGINE=INNODB; включил, в следующий раз упадет - покажу логи.
Сегодня ночью переключал на новый сервер с 4 ssd v5.3.38, надеюсь что вообще не упадет больше - ну или хотя бы пореже ))
Database changed
mysql> CREATE TABLE innodb_monitor (a INT) ENGINE=INNODB;
Query OK, 0 rows affected (0.01 sec)
mysql> select version();
+-----------------------------+
| version() |
+-----------------------------+
| 5.5.38-0ubuntu0.14.04.1-log |
+-----------------------------+
1 row in set (0.00 sec)
On Monday, October 13, 2014 6:05:03 PM UTC+6, svetasmirnova wrote:
--
---
Вы получили это сообщение, поскольку подписаны на группу "Moscow MySQL User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес moscow-mysql-user...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Viacheslav Romanov
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес moscow-mysql-user-group+unsub...@googlegroups.com.
Sergey Bezrukov
--
WBR,
Serge.
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес moscow-mysql-user...@googlegroups.com.
Viacheslav Romanov
Slach
там куча тредов в таком состоянии
это значит что innodb_lock_monitor не включен или что включен?
Народ, подскажите пожалуйста?
это все может быть потому что какой то flush на диск переводит innodb в какой то sync режим?
если да то какой
Вячеслав, скиньте сюда в тред пожалуйста
SHOW VARIABLES LIKE '%innodb%'; ?
и еще судя по тому что большое кол-во NULL в SHOW PROCESS LIST
может все таки попробовать заменить mysql_pconnect на mysql_connect?
Viacheslav Romanov
Насколько я понял по всем логам проблема тут:
--Thread 139785057793792 has waited at btr0cur.c line 536 for 0.00 seconds the semaphore:
S-lock on RW-latch at 0x7f22dc0c0278 created in file dict0dict.c line 1843
a writer (thread id 139785486698240) has reserved it in mode wait exclusive
number of readers 171, waiters flag 1, lock_word: ffffffffffffff55
Last time read locked in file btr0cur.c line 536
Last time write locked in file /build/buildd/mysql-5.5-5.5.38/storage/innobase/btr/btr0cur.c line 529
--Thread 139785184839424 has waited at trx0trx.c line 1684 for 0.00 seconds the semaphore:
Mutex at 0x7f645163a288 created file srv0srv.c line 1024, lock var 1
waiters flag 1
--Thread 139785196480256 has waited at btr0cur.c line 536 for 2.00 seconds the semaphore:
S-lock on RW-latch at 0x7f22dc0c0278 created in file dict0dict.c line 1843
a writer (thread id 139785486698240) has reserved it in mode wait exclusive
number of readers 171, waiters flag 1, lock_word: ffffffffffffff55
Last time read locked in file btr0cur.c line 536
On Tuesday, October 14, 2014 10:29:53 AM UTC+6, Slach wrote:
Насколько я понял по последнему лог файлу
там куча тредов в таком состоянии--Thread 139795399268096 has waited at row0ins.c line 2027 for 3.00 seconds the semaphore:X-lock on RW-latch at 0x7f2774ece8c0 created in file buf0buf.c line 938a writer (thread id 139785327740672) has reserved it in mode exclusivenumber of readers 0, waiters flag 1, lock_word: 0Last time read locked in file row0sel.c line 3908Last time write locked in file /build/buildd/mysql-5.5-5.5.38/storage/innobase/row/row0upd.c line 2144
это значит что innodb_lock_monitor не включен или что включен?
Народ, подскажите пожалуйста?
это все может быть потому что какой то flush на диск переводит innodb в какой то sync режим?
если да то какой
Вячеслав, скиньте сюда в тред пожалуйста
SHOW VARIABLES LIKE '%innodb%'; ?
mysql> show variables like '%innodb%';
+---------------------------------+------------------------+
| Variable_name | Value |
+---------------------------------+------------------------+
| have_innodb | YES |
| ignore_builtin_innodb | OFF |
| innodb_adaptive_flushing | ON |
| innodb_adaptive_hash_index | ON |
| innodb_additional_mem_pool_size | 134217728 |
| innodb_autoextend_increment | 1000 |
| innodb_autoinc_lock_mode | 1 |
| innodb_buffer_pool_instances | 1 |
| innodb_buffer_pool_size | 257698037760 |
| innodb_change_buffering | all |
| innodb_checksums | ON |
| innodb_commit_concurrency | 0 |
| innodb_concurrency_tickets | 500 |
| innodb_data_file_path | ibdata1:10M:autoextend |
| innodb_data_home_dir | |
| innodb_doublewrite | ON |
| innodb_fast_shutdown | 1 |
| innodb_file_format | Antelope |
| innodb_file_format_check | ON |
| innodb_file_format_max | Antelope |
| innodb_file_per_table | OFF |
| innodb_flush_log_at_trx_commit | 0 |
| innodb_flush_method | |
| innodb_force_load_corrupted | OFF |
| innodb_force_recovery | 0 |
| innodb_io_capacity | 3000 |
| innodb_large_prefix | OFF |
| innodb_lock_wait_timeout | 50 |
| innodb_locks_unsafe_for_binlog | OFF |
| innodb_log_buffer_size | 33554432 |
| innodb_log_file_size | 536870912 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | ./ |
| innodb_max_dirty_pages_pct | 75 |
| innodb_max_purge_lag | 0 |
| innodb_mirrored_log_groups | 1 |
| innodb_old_blocks_pct | 37 |
| innodb_old_blocks_time | 0 |
| innodb_open_files | 300 |
| innodb_print_all_deadlocks | OFF |
| innodb_purge_batch_size | 20 |
| innodb_purge_threads | 0 |
| innodb_random_read_ahead | OFF |
| innodb_read_ahead_threshold | 56 |
| innodb_read_io_threads | 4 |
| innodb_replication_delay | 0 |
| innodb_rollback_on_timeout | OFF |
| innodb_rollback_segments | 128 |
| innodb_spin_wait_delay | 6 |
| innodb_stats_method | nulls_equal |
| innodb_stats_on_metadata | ON |
| innodb_stats_sample_pages | 8 |
| innodb_strict_mode | OFF |
| innodb_support_xa | OFF |
| innodb_sync_spin_loops | 30 |
| innodb_table_locks | ON |
| innodb_thread_concurrency | 0 |
| innodb_thread_sleep_delay | 10000 |
| innodb_use_native_aio | ON |
| innodb_use_sys_malloc | ON |
| innodb_version | 5.5.38 |
| innodb_write_io_threads | 4 |
+---------------------------------+------------------------+
62 rows in set (0.00 sec)
Sveta Smirnova
On 10/13/2014 07:46 PM, Viacheslav Romanov wrote:
Ну и собственно что и ожидалось - упало прямо сейчас
SHOW ENGINE INNODB STATUS & SHOW PROCESSLIST в аттаче
Спящие процессы в статусе "transaction not started" и, по идее, держать блокировок на уровне InnoDB не должны.
Пришлите вывод SHOW CREATE TABLE users и конфигурационный файл: посмотрим, почему так много транзакций в статусе "starting index read".
Света.
On Monday, October 13, 2014 10:12:40 PM UTC+6, Viacheslav Romanov wrote:
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес moscow-mysql-user...@googlegroups.com.
Sveta Smirnova
On 10/14/2014 07:29 AM, Slach wrote:
Насколько я понял по последнему лог файлу
там куча тредов в таком состоянии
--Thread 139795399268096 has waited at row0ins.c line 2027 for 3.00 seconds the semaphore:X-lock on RW-latch at 0x7f2774ece8c0 created in file buf0buf.c line 938a writer (thread id 139785327740672) has reserved it in mode exclusivenumber of readers 0, waiters flag 1, lock_word: 0Last time read locked in file row0sel.c line 3908Last time write locked in file /build/buildd/mysql-5.5-5.5.38/storage/innobase/row/row0upd.c line 2144
это значит что innodb_lock_monitor не включен или что включен?
Народ, подскажите пожалуйста?
TRANSACTION 0 26244357, ACTIVE 1 sec,
OS thread id 101357568 starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 320, 1 row lock(s)
MySQL thread id 217, query id 95 localhost root Updating
update t set a=36 where a=6
TRX HAS BEEN WAITING 1 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 349 page no 3 n bits 88
index `PRIMARY` of table `test`.`t`
trx id 0 26244357 lock_mode X locks rec
but not gap waiting
Record lock, heap no 6 PHYSICAL RECORD: n_fields 3;
compact format; info bits 32
0: len 4; hex 00000006; asc
;; 1: len 6; hex 000001907504; asc
u ;; 2:
len 7; hex 0000000032081c; asc
2 ;;
TABLE LOCK table `test`.`t` trx id 0 26244357
lock mode IX
RECORD LOCKS space id 349 page no 3 n bits 88
index `PRIMARY` of table `test`.`t`
trx id 0 26244357 lock_mode X locks rec
but not gap waiting
Record lock, heap no 6 PHYSICAL RECORD: n_fields 3;
compact format; info bits 32
0: len 4; hex 00000006; asc
;; 1: len 6; hex 000001907504; asc
U ;; 2:
len 7; hex 0000000032081c; asc
2 ;;
TRANSACTION 0 26244356, ACTIVE 6 sec,
OS thread id 101099008
2 lock struct(s), heap size 320, 1 row lock(s),
undo log entries 2
MySQL thread id 184, query id 93 localhost root
TABLE LOCK table `test`.`t` trx id 0 26244356
lock mode IX
RECORD LOCKS space id 349 page no 3 n bits 88
index `PRIMARY` of table `test`.`t`
trx id 0 26244356 lock_mode X locks rec but not gap
Record lock, heap no 6 PHYSICAL RECORD: n_fields 3;
compact format; info bits 32
0: len 4; hex 00000006; asc
;; 1: len 6; hex 000001907504; asc
u ;; 2:
len 7; hex 0000000032081c; asc
2 ;;
Света.
это все может быть потому что какой то flush на диск переводит innodb в какой то sync режим?
если да то какой
Вячеслав, скиньте сюда в тред пожалуйста
SHOW VARIABLES LIKE '%innodb%'; ?
и еще судя по тому что большое кол-во NULL в SHOW PROCESS LIST
может все таки попробовать заменить mysql_pconnect на mysql_connect?
Sveta Smirnova
On 10/13/2014 07:03 PM, Viacheslav Romanov wrote:
Насколько я понял речь о core dump - в error.log было бы об этом упоминание, но там чисто.
Узнаю о них когда приложение "виснет" - не выполняются никакие запросы. В заббиксе падает запись на диск практически до нуля, в innodb status куча семафоров.
Отключаю приложение - киляю всех клиентов (php) - запускаю - работает (уже скрипт есть, удобно)
Света.
--
Viacheslav Romanov
On Wednesday, October 15, 2014 6:11:46 PM UTC+6, svetasmirnova wrote:
Привет!
On 10/13/2014 07:46 PM, Viacheslav Romanov wrote:Ну и собственно что и ожидалось - упало прямо сейчас
SHOW ENGINE INNODB STATUS & SHOW PROCESSLIST в аттаче
В общем проблем блокировок строк я тут не вижу или вы очень быстро убиваете ожидающие процессы. В случае проблем блокировок, дедлоков и т.п. в списке TRANSACTIONS как правило есть транзакции, которые работают по несколько секунд (больше, чем среднее) и держат лок. У вас же наиболее долгоиграющие в статусе "starting index read" и есть несколько в "sending data" и "updating" (те могут ждать локов/держать локи на самом деле, но они бы были в этом статусе сильно больше, чем в среднем по процесслисту).
Спящие процессы в статусе "transaction not started" и, по идее, держать блокировок на уровне InnoDB не должны.
Пришлите вывод SHOW CREATE TABLE users и конфигурационный файл: посмотрим, почему так много транзакций в статусе "starting index read".
mysql> show create table users\G
*************************** 1. row ***************************
Table: users
Create Table: CREATE TABLE `users` (
`userId` bigint(20) unsigned NOT NULL,
`episode` tinyint(4) NOT NULL,
`level` tinyint(4) NOT NULL,
`coins` int(11) NOT NULL,
`receivedKeys` varchar(100) NOT NULL DEFAULT '',
`refPlace` varchar(30) NOT NULL DEFAULT '',
`lastLogin` date NOT NULL,
`firstLogin` date NOT NULL,
`paid` tinyint(4) NOT NULL DEFAULT '0',
`lastPublication` int(10) unsigned NOT NULL,
`lastGift` int(10) unsigned NOT NULL,
`strip` tinyint(4) NOT NULL DEFAULT '0',
`friendsHelpSended` tinyint(4) NOT NULL DEFAULT '0',
`lastLevelPass` date NOT NULL,
`lastPayDate` date NOT NULL,
`getCoinsForInviteTime` int(10) unsigned NOT NULL,
`powerUps` int(10) unsigned NOT NULL DEFAULT '0',
`collectAction` tinyint(3) unsigned NOT NULL DEFAULT '0',
`amountCollectCoinsFromFriends` int(10) unsigned NOT NULL DEFAULT '0',
`shownForces` int(10) unsigned NOT NULL DEFAULT '0',
`bonusLevelPlayTime` int(11) NOT NULL DEFAULT '0',
`everydayBonusSeria` tinyint(4) NOT NULL DEFAULT '0',
`everydayBonusCollected` tinyint(4) NOT NULL DEFAULT '0',
`withoutLoseSeria` int(11) NOT NULL DEFAULT '0',
`todayGachaPlayTimes` int(11) NOT NULL DEFAULT '0',
`achievements` bigint(20) NOT NULL DEFAULT '0',
PRIMARY KEY (`userId`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)
key_buffer_size = 128M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 3000
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover = BACKUP
max_connections = 3000
table_open_cache = 10000
thread_concurrency = 24
max_heap_table_size = 2G
max_connect_errors = 1000000000
#
# * Query Cache Configuration
#
query_cache_limit = 0
query_cache_size = 0
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file = /var/log/mysql/mysql.log
#general_log = 1
log_error = /var/log/mysql/error.log
log_warnings = 2
# Here you can see queries with especially long duration
log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 0.2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
# other settings you may need to change.
server-id=101
log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 3
max_binlog_size = 128M
#binlog_do_db = include_database_name
#binlog_ignore_db = include_database_name
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
#
innodb_autoextend_increment = 1000
innodb_buffer_pool_size = 240G
innodb_additional_mem_pool_size = 128M
innodb_log_file_size = 512M
innodb_log_buffer_size = 32M
innodb_flush_log_at_trx_commit = 0
innodb_io_capacity = 3000
#concurrency ??
#file_per_table ???
#pool_instances ???
#???
#innodb_use_sys_malloc = 1
# danger!
innodb_support_xa = 0
#binlog_cache_size = 1M
#read_buffer_size = 1M
#sort_buffer_size = 2M
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem
[mysqldump]
quick
quote-names
max_allowed_packet = 1G
[mysql]
#no-auto-rehash # faster start of mysql but no tab completition
[isamchk]
key_buffer_size = 512M
Viacheslav Romanov
Привет!
On 10/13/2014 07:03 PM, Viacheslav Romanov wrote:Кстати, если приложения восстанавливается после "киляния", имеет смысл просто уменьшить innodb_lock_wait_timeout до минимального значения (1) или до скольких вашему приложению возможно ждать (значение по умолчанию 50 секунд). Тогда все транзакции, которые ждут локов слишком долго, будут автоматически убиваться.Насколько я понял речь о core dump - в error.log было бы об этом упоминание, но там чисто.
Узнаю о них когда приложение "виснет" - не выполняются никакие запросы. В заббиксе падает запись на диск практически до нуля, в innodb status куча семафоров.
Отключаю приложение - киляю всех клиентов (php) - запускаю - работает (уже скрипт есть, удобно)
Света.
--
On Monday, October 13, 2014 3:01:20 PM UTC+6, Konstantin Osipov wrote:* Viacheslav Romanov <rvv...@gmail.com> [14/10/13 12:23]:
> Нет текста ошибки при дедлоке. А корка что такое?
А как вы узнаёте о них? только по innodb status?
--
http://tarantool.org - an efficient, extensible in-memory data store
---
Вы получили это сообщение, поскольку подписаны на группу "Moscow MySQL User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес moscow-mysql-user-group+unsub...@googlegroups.com.
Sveta Smirnova
On 10/15/2014 08:30 PM, Viacheslav Romanov wrote:
On Wednesday, October 15, 2014 6:18:38 PM UTC+6, svetasmirnova wrote:
Привет!
On 10/13/2014 07:03 PM, Viacheslav Romanov wrote:Кстати, если приложения восстанавливается после "киляния", имеет смысл просто уменьшить innodb_lock_wait_timeout до минимального значения (1) или до скольких вашему приложению возможно ждать (значение по умолчанию 50 секунд). Тогда все транзакции, которые ждут локов слишком долго, будут автоматически убиваться.Насколько я понял речь о core dump - в error.log было бы об этом упоминание, но там чисто.
Узнаю о них когда приложение "виснет" - не выполняются никакие запросы. В заббиксе падает запись на диск практически до нуля, в innodb status куча семафоров.
Отключаю приложение - киляю всех клиентов (php) - запускаю - работает (уже скрипт есть, удобно)
Попробую - но это все-таки временное решение, даже если поможет. Вообще говороя, после киляние не всегда восстанавливается - там нужно стопнуть все, кильнуть потоки и подождать секунд 10 - тогда обычно работает.
Кстати, обычно неплохое. Единственное, приложение должно быть написано таким образом, чтобы перезапустить транзакцию после того, как она была roll back.
Я подозреваю что проблема в checkpoint age - просто почему-то не флашит, а просто виснет. Ну это тоже теория - увеличил io_capacity, буду наблюдать
"For busy systems capable of higher I/O rates, you can set a higher value at server startup, to help the server handle the background maintenance work associated with a high rate of row changes. For systems with individual 5400 RPM or 7200 RPM drives, you might lower the value to the former default of
100."
(http://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_io_capacity)
Впрочем, судя по тому, что у вас innodb_buffer_pool_size 240G диски
у вас тоже должны быть быстрые...Ещё имеет смысл увеличить innodb_log_file_size до максимального значения (если у вас innodb_log_files_in_group по умолчанию 2, то для MySQL 5.5 это 2G).
Также во всех представленных выводах InnoDB Monitor есть вот такое:
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
insert 0, delete mark 0, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
Hash table size 509994437, node heap has 149087 buffer(s)
349.65 hash searches/s, 21282.72 non-hash searches/s
То есть adaptive hash index используется неэффективно на ваших запросах. Можно попробовать его отключить и потестировать.
Коммент по поводу SHOW CREATE TABLE: тут всё нормально, вы ищете по единственному индексу в таблице.
Света.
Света.
--
On Monday, October 13, 2014 3:01:20 PM UTC+6, Konstantin Osipov wrote:* Viacheslav Romanov <rvv...@gmail.com> [14/10/13 12:23]:
> Нет текста ошибки при дедлоке. А корка что такое?
А как вы узнаёте о них? только по innodb status?
--
http://tarantool.org - an efficient, extensible in-memory data store
---
Вы получили это сообщение, поскольку подписаны на группу "Moscow MySQL User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес moscow-mysql-user-group+unsub...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.