From 354b523695490708ea2d9fd4d4205b691884cd80 Mon Sep 17 00:00:00 2001 From: DMRobertson Date: Tue, 17 May 2022 10:01:15 +0000 Subject: deploy: 44d7bb13c357fb8cb6ff7c75f5abc189fa530529 --- latest/usage/administration/request_log.html | 2 +- .../administration/useful_sql_for_admins.html | 154 +++++++++++++-------- .../usage/configuration/config_documentation.html | 17 ++- .../configuration/homeserver_sample_config.html | 21 ++- .../usage/configuration/logging_sample_config.html | 7 - 5 files changed, 127 insertions(+), 74 deletions(-) (limited to 'latest/usage') diff --git a/latest/usage/administration/request_log.html b/latest/usage/administration/request_log.html index 47b1defb1e..81b34fc9cf 100644 --- a/latest/usage/administration/request_log.html +++ b/latest/usage/administration/request_log.html @@ -169,7 +169,7 @@ NNNNTotal time waiting for response to DB queries across all parallel DB work from this request OOOOCount of DB transactions performed PPPPResponse body size -QQQQResponse status code (prefixed with ! if the socket was closed before the response was generated) +QQQQResponse status code
Suffixed with ! if the socket was closed before the response was generated.
A 499! status code indicates that Synapse also cancelled request processing after the socket was closed.
RRRRRequest SSSSUser-agent TTTTEvents fetched from DB to service this request (note that this does not include events fetched from the cache) diff --git a/latest/usage/administration/useful_sql_for_admins.html b/latest/usage/administration/useful_sql_for_admins.html index 308b1870f7..e6a8059845 100644 --- a/latest/usage/administration/useful_sql_for_admins.html +++ b/latest/usage/administration/useful_sql_for_admins.html @@ -148,40 +148,23 @@

Some useful SQL queries for Synapse Admins

Size of full matrix db

-

SELECT pg_size_pretty( pg_database_size( 'matrix' ) );

+
SELECT pg_size_pretty( pg_database_size( 'matrix' ) );
+

Result example:

pg_size_pretty 
 ----------------
  6420 MB
 (1 row)
-

Show top 20 larger rooms by state events count

-
SELECT r.name, s.room_id, s.current_state_events
-  FROM room_stats_current s
-  LEFT JOIN room_stats_state r USING (room_id)
-  ORDER BY current_state_events DESC
-  LIMIT 20;
-
-

and by state_group_events count:

-
SELECT rss.name, s.room_id, count(s.room_id) FROM state_groups_state s
-LEFT JOIN room_stats_state rss USING (room_id)
-GROUP BY s.room_id, rss.name        
-ORDER BY count(s.room_id) DESC
-LIMIT 20;
-
-

plus same, but with join removed for performance reasons:

-
SELECT s.room_id, count(s.room_id) FROM state_groups_state s
-GROUP BY s.room_id        
-ORDER BY count(s.room_id) DESC
-LIMIT 20;
-

Show top 20 larger tables by row count

-
SELECT relname, n_live_tup as rows
-  FROM pg_stat_user_tables 
+
SELECT relname, n_live_tup AS "rows"
+  FROM pg_stat_user_tables
   ORDER BY n_live_tup DESC
   LIMIT 20;
 

-
This query is quick, but may be very approximate, for exact number of rows use SELECT COUNT(*) FROM <table_name>.

+
This query is quick, but may be very approximate, for exact number of rows use:

+
SELECT COUNT(*) FROM <table_name>;
+

 
Result example:

 
state_groups_state - 161687170
 event_auth - 8584785
@@ -204,37 +187,15 @@ users_in_public_rooms - 364059
 device_lists_stream - 326903
 user_directory_search - 316433
 

-
Show top 20 rooms by new events count in last 1 day:

-
SELECT e.room_id, r.name, COUNT(e.event_id) cnt FROM events e
-LEFT JOIN room_stats_state r USING (room_id)
-WHERE e.origin_server_ts >= DATE_PART('epoch', NOW() - INTERVAL '1 day') * 1000 GROUP BY e.room_id, r.name ORDER BY cnt DESC LIMIT 20;
-

-
Show top 20 users on homeserver by sent events (messages) at last month:

-
SELECT user_id, SUM(total_events) 
-   FROM user_stats_historical
-   WHERE TO_TIMESTAMP(end_ts/1000) AT TIME ZONE 'UTC' > date_trunc('day', now() - interval '1 month')
-   GROUP BY user_id
-   ORDER BY SUM(total_events) DESC 
-   LIMIT 20;
-

-
Show last 100 messages from needed user, with room names:

-
SELECT e.room_id, r.name, e.event_id, e.type, e.content, j.json FROM events e
-  LEFT JOIN event_json j USING (room_id)
-  LEFT JOIN room_stats_state r USING (room_id)
-  WHERE sender = '@LOGIN:example.com'
-  AND e.type = 'm.room.message'
-  ORDER BY stream_ordering DESC
-  LIMIT 100;
-

 
Show top 20 larger tables by storage size

 
SELECT nspname || '.' || relname AS "relation",
-    pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size"
-  FROM pg_class C
-  LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
+    pg_size_pretty(pg_total_relation_size(c.oid)) AS "total_size"
+  FROM pg_class c
+  LEFT JOIN pg_namespace n ON (n.oid = c.relnamespace)
   WHERE nspname NOT IN ('pg_catalog', 'information_schema')
-    AND C.relkind <> 'i'
+    AND c.relkind <> 'i'
     AND nspname !~ '^pg_toast'
-  ORDER BY pg_total_relation_size(C.oid) DESC
+  ORDER BY pg_total_relation_size(c.oid) DESC
   LIMIT 20;
 

 
Result example:

@@ -259,8 +220,75 @@ public.state_groups - 160 MB
 public.device_lists_remote_cache - 124 MB
 public.state_group_edges - 122 MB
+

Show top 20 larger rooms by state events count

+

You get the same information when you use the +admin API +and set parameter order_by=state_events.

+
SELECT r.name, s.room_id, s.current_state_events
+  FROM room_stats_current s
+  LEFT JOIN room_stats_state r USING (room_id)
+  ORDER BY current_state_events DESC
+  LIMIT 20;
+
+

and by state_group_events count:

+
SELECT rss.name, s.room_id, COUNT(s.room_id)
+  FROM state_groups_state s
+  LEFT JOIN room_stats_state rss USING (room_id)
+  GROUP BY s.room_id, rss.name
+  ORDER BY COUNT(s.room_id) DESC
+  LIMIT 20;
+
+

plus same, but with join removed for performance reasons:

+
SELECT s.room_id, COUNT(s.room_id)
+  FROM state_groups_state s
+  GROUP BY s.room_id 
+  ORDER BY COUNT(s.room_id) DESC
+  LIMIT 20;
+
+

Show top 20 rooms by new events count in last 1 day:

+
SELECT e.room_id, r.name, COUNT(e.event_id) cnt
+  FROM events e
+  LEFT JOIN room_stats_state r USING (room_id)
+  WHERE e.origin_server_ts >= DATE_PART('epoch', NOW() - INTERVAL '1 day') * 1000
+  GROUP BY e.room_id, r.name 
+  ORDER BY cnt DESC
+  LIMIT 20;
+
+

Show top 20 users on homeserver by sent events (messages) at last month:

+

Caution. This query does not use any indexes, can be slow and create load on the database.

+
SELECT COUNT(*), sender
+  FROM events
+  WHERE (type = 'm.room.encrypted' OR type = 'm.room.message')
+    AND origin_server_ts >= DATE_PART('epoch', NOW() - INTERVAL '1 month') * 1000
+  GROUP BY sender
+  ORDER BY COUNT(*) DESC
+  LIMIT 20;
+
+

Show last 100 messages from needed user, with room names:

+
SELECT e.room_id, r.name, e.event_id, e.type, e.content, j.json
+  FROM events e
+  LEFT JOIN event_json j USING (room_id)
+  LEFT JOIN room_stats_state r USING (room_id)
+  WHERE sender = '@LOGIN:example.com'
+    AND e.type = 'm.room.message'
+  ORDER BY stream_ordering DESC
+  LIMIT 100;
+

Show rooms with names, sorted by events in this rooms

-

echo "select event_json.room_id,room_stats_state.name from event_json,room_stats_state where room_stats_state.room_id=event_json.room_id" | psql synapse | sort | uniq -c | sort -n

+

Sort and order with bash

+
echo "SELECT event_json.room_id, room_stats_state.name FROM event_json, room_stats_state \
+WHERE room_stats_state.room_id = event_json.room_id" | psql -d synapse -h localhost -U synapse_user -t \
+| sort | uniq -c | sort -n
+
+

Documentation for psql command line parameters: https://www.postgresql.org/docs/current/app-psql.html

+

Sort and order with SQL

+
SELECT COUNT(*), event_json.room_id, room_stats_state.name
+  FROM event_json, room_stats_state
+  WHERE room_stats_state.room_id = event_json.room_id
+  GROUP BY event_json.room_id, room_stats_state.name
+  ORDER BY COUNT(*) DESC
+  LIMIT 50;
+

Result example:

   9459  !FPUfgzXYWTKgIrwKxW:matrix.org              | This Week in Matrix
    9459  !FPUfgzXYWTKgIrwKxW:matrix.org              | This Week in Matrix (TWIM)
@@ -272,13 +300,21 @@ public.state_group_edges - 122 MB
   43601  !iNmaIQExDMeqdITdHH:matrix.org              | Riot Web/Desktop

Lookup room state info by list of room_id

-
SELECT rss.room_id, rss.name, rss.canonical_alias, rss.topic, rss.encryption, rsc.joined_members, rsc.local_users_in_room, rss.join_rules
-FROM room_stats_state rss
-LEFT JOIN room_stats_current rsc USING (room_id)
-WHERE room_id IN (WHERE room_id IN (
- '!OGEhHVWSdvArJzumhm:matrix.org',
- '!YTvKGNlinIzlkMTVRl:matrix.org'
-)
+
You get the same information when you use the
+admin API.

+
SELECT rss.room_id, rss.name, rss.canonical_alias, rss.topic, rss.encryption,
+    rsc.joined_members, rsc.local_users_in_room, rss.join_rules
+  FROM room_stats_state rss
+  LEFT JOIN room_stats_current rsc USING (room_id)
+  WHERE room_id IN ( WHERE room_id IN (
+    '!OGEhHVWSdvArJzumhm:matrix.org',
+    '!YTvKGNlinIzlkMTVRl:matrix.org' 
+  );
+

+
Show users and devices that have not been online for a while

+
SELECT user_id, device_id, user_agent, TO_TIMESTAMP(last_seen / 1000) AS "last_seen"
+  FROM devices
+  WHERE last_seen < DATE_PART('epoch', NOW() - INTERVAL '3 month') * 1000;
 

 
                     
diff --git a/latest/usage/configuration/config_documentation.html b/latest/usage/configuration/config_documentation.html
index e0c2459f3b..0603e07295 100644
--- a/latest/usage/configuration/config_documentation.html
+++ b/latest/usage/configuration/config_documentation.html
@@ -660,6 +660,17 @@ session. Defaults to 0. 

 
mau_trial_days: 5
 

 

+
Config option: mau_appservice_trial_days

+
The option mau_appservice_trial_days is similar to mau_trial_days, but applies a different
+trial number if the user was registered by an appservice. A value
+of 0 means no trial days are applied. Appservices not listed in this dictionary
+use the value of mau_trial_days instead.

+
Example configuration:

+
mau_appservice_trial_days: 
+  my_appservice_id: 3
+  another_appservice_id: 6
+

+

 
Config option: mau_limit_alerting

 
The option mau_limit_alerting is a means of limiting client-side alerting
 should the mau limit be reached. This is useful for small instances
@@ -975,11 +986,11 @@ on this homeserver.

Config option: allow_device_name_lookup_over_federation

-

Set this option to false to disable device display name lookup over federation. By default, the -Federation API allows other homeservers to obtain device display names of any user +

Set this option to true to allow device display name lookup over federation. By default, the +Federation API prevents other homeservers from obtaining the display names of any user devices on this homeserver.

Example configuration:

-
allow_device_name_lookup_over_federation: false
+
allow_device_name_lookup_over_federation: true
 

 

 
Caching

diff --git a/latest/usage/configuration/homeserver_sample_config.html b/latest/usage/configuration/homeserver_sample_config.html
index 836ae803f0..ec9c6791ec 100644
--- a/latest/usage/configuration/homeserver_sample_config.html
+++ b/latest/usage/configuration/homeserver_sample_config.html
@@ -563,6 +563,11 @@ manhole_settings:
 # sign up in a short space of time never to return after their initial
 # session.
 #
+# The option `mau_appservice_trial_days` is similar to `mau_trial_days`, but
+# applies a different trial number if the user was registered by an appservice.
+# A value of 0 means no trial days are applied. Appservices not listed in this
+# dictionary use the value of `mau_trial_days` instead.
+#
 # 'mau_limit_alerting' is a means of limiting client side alerting
 # should the mau limit be reached. This is useful for small instances
 # where the admin has 5 mau seats (say) for 5 specific people and no
@@ -573,6 +578,8 @@ manhole_settings:
 #max_mau_value: 50
 #mau_trial_days: 2
 #mau_limit_alerting: false
+#mau_appservice_trial_days:
+#  "appservice-id": 1
 
 # If enabled, the metrics for the number of monthly active users will
 # be populated, however no one will be limited. If limit_usage_by_mau
@@ -865,11 +872,11 @@ retention:
 #
 #allow_profile_lookup_over_federation: false
 
-# Uncomment to disable device display name lookup over federation. By default, the
-# Federation API allows other homeservers to obtain device display names of any user
-# on this homeserver. Defaults to 'true'.
+# Uncomment to allow device display name lookup over federation. By default, the
+# Federation API prevents other homeservers from obtaining the display names of
+# user devices on this homeserver. Defaults to 'false'.
 #
-#allow_device_name_lookup_over_federation: false
+#allow_device_name_lookup_over_federation: true
 
 
 ## Caching ##
@@ -1479,6 +1486,12 @@ oembed:
 #
 #registration_requires_token: true
 
+# Allow users to submit a token during registration to bypass any required 3pid
+# steps configured in `registrations_require_3pid`.
+# Defaults to false, requiring that registration tokens (if enabled) complete a 3pid flow.
+#
+#enable_registration_token_3pid_bypass: false
+
 # If set, allows registration of standard or admin accounts by anyone who
 # has the shared secret, even if registration is otherwise disabled.
 #
diff --git a/latest/usage/configuration/logging_sample_config.html b/latest/usage/configuration/logging_sample_config.html
index fca0918503..7f22f2cba4 100644
--- a/latest/usage/configuration/logging_sample_config.html
+++ b/latest/usage/configuration/logging_sample_config.html
@@ -218,13 +218,6 @@ loggers:
         # information such as access tokens.
         level: INFO
 
-    twisted:
-        # We send the twisted logging directly to the file handler,
-        # to work around https://github.com/matrix-org/synapse/issues/3471
-        # when using "buffer" logger. Use "console" to log to stderr instead.
-        handlers: [file]
-        propagate: false
-
 root:
     level: INFO
 
-- 
cgit 1.5.1