Notices by abjectio (knuthollund@quitter.no), page 2

abjectio (knuthollund@quitter.no)'s status on Monday, 18-Jun-2018 13:47:40 EDT abjectio
- Thor, the Norseman has moved!
@thor Thanks.

In conversation Monday, 18-Jun-2018 13:47:40 EDT from quitter.no permalink
abjectio (knuthollund@quitter.no)'s status on Sunday, 17-Jun-2018 14:23:53 EDT abjectio
- QuitterNo
Message to users of quitter.no. I've decided to close this site on it's 4th birthday, that is 5th September -18. I do not have the energy and capacity to host the site anymore. Please "migrate" or find a new GNU Social home. I've decided to not handover the maintenance or data to anyone else - so please do not ask to get the data to host this site further. Thank you all for using Quitter this period and for following it's users. - A. !quitterno #gnusocial #quitter

In conversation Sunday, 17-Jun-2018 14:23:53 EDT from quitter.no permalink
abjectio (knuthollund@quitter.no)'s status on Saturday, 09-Jun-2018 18:20:36 EDT abjectio
- @mcscx2@quitter.no
- Autodefensa Informática
@ai @mcscx2 yeah... something went wrong - I don't know what, so the local guy at the hackerspace was needed to kick it alive (or to fix the network issue - the server was never down).

In conversation Saturday, 09-Jun-2018 18:20:36 EDT from quitter.no permalink
abjectio (knuthollund@quitter.no)'s status on Thursday, 07-Jun-2018 17:07:44 EDT abjectio
in reply to
- @mcscx2@quitter.no
- Autodefensa Informática
@mcscx2 @ai my fault .... was on ipv6 - could reproduce unable to connect now. restarted nginx - back on ipv4 again. hmmm strange.

In conversation Thursday, 07-Jun-2018 17:07:44 EDT from quitter.no permalink
abjectio (knuthollund@quitter.no)'s status on Wednesday, 06-Jun-2018 17:27:04 EDT abjectio
in reply to
- @mcscx2@quitter.no
@mcscx2 Been away for a while .... Thanks for all your effort and investigation. Interesting stuff. Did some config now, not sure if it helps. Tell me if you see some changes - and yes, I'm on IPv6 at home.

In conversation Wednesday, 06-Jun-2018 17:27:04 EDT from quitter.no permalink
abjectio (knuthollund@quitter.no)'s status on Wednesday, 30-May-2018 15:16:15 EDT abjectio
in reply to
- Sorokin Alexei
@xrevan86 could you guide me how to do this. I guess appending a fulltext "column" - then change the query ?

In conversation Wednesday, 30-May-2018 15:16:15 EDT from quitter.no permalink
abjectio (knuthollund@quitter.no)'s status on Wednesday, 30-May-2018 12:26:12 EDT abjectio
in reply to
@xrevan86 @mcscx2 @maiyannah tx - implemented on q.no....

In conversation Wednesday, 30-May-2018 12:26:12 EDT from quitter.no permalink
abjectio (knuthollund@quitter.no)'s status on Tuesday, 29-May-2018 12:50:22 EDT abjectio
in reply to
@mcscx2 @lakwnikos @xrevan86 @maiyannah ohhh - please share if you have a patch for this! I tried running the queries manually and yes - they are slow... (typically 16seconds pr. run - if you re-run, they will be in memory and execute less than a second)

In conversation Tuesday, 29-May-2018 12:50:22 EDT from quitter.no permalink
abjectio (knuthollund@quitter.no)'s status on Monday, 28-May-2018 17:33:47 EDT abjectio
in reply to
- lakwnikos
- @mcscx2@quitter.no
@mcscx2 @lakwnikos Ref previous comment - maybe "LIMIT ROWS EXAMIED" - should be implemented? - https://mariadb.com/kb/en/library/limit-rows-examined/
In conversation Monday, 28-May-2018 17:33:47 EDT from quitter.no permalink
Attachments
1. Unable to connect to tcp://mariadb.comaskmonty-logo.png:80. Error: php_network_getaddresses: getaddrinfo failed: Name or service not known
  
  LIMIT ROWS EXAMINED
  
  from MariaDB KnowledgeBase
  
  Means to terminate execution of SELECTs that examine too many rows
abjectio (knuthollund@quitter.no)'s status on Monday, 28-May-2018 17:13:28 EDT abjectio
in reply to
- lakwnikos
- @mcscx2@quitter.no
@mcscx2 @lakwnikos don't think there is a ddos. A classical slow query is the following example (examine 3mill rows).
"# Query_time: 16.042286 Lock_time: 0.000140 Rows_sent: 104 Rows_examined: 3776090
# Rows_affected: 0
SET timestamp=1527533585;
SELECT id FROM notice
WHERE ( notice.created > "2018-01-14 23:36:01" ) AND ( notice.id IN (SELECT notice_id FROM reply WHERE profile_id=45991) OR notice.profile_id IN (SELECT subscribed FROM subscription WHERE subscriber=45991) OR notice.id IN (SELECT notice_id FROM group_inbox WHERE group_id IN (SELECT group_id FROM group_member WHERE profile_id=45991))OR notice.id IN (SELECT notice_id FROM attention WHERE profile_id=45991) )
ORDER BY notice.id DESC
LIMIT 0, 200;"
Also query's from the search field do a "LIKE '%yoursearch%" - which takes a long time - like does not use indexes. However, the select above (example 1) is the one reporting often as the slow queries.

In conversation Monday, 28-May-2018 17:13:28 EDT from quitter.no permalink
abjectio (knuthollund@quitter.no)'s status on Monday, 07-May-2018 09:25:26 EDT abjectio
- @mcscx2@quitter.no
@mcscx2 no - the server does not log anything from the network except what’s stored in the GNU social db.

In conversation Monday, 07-May-2018 09:25:26 EDT from quitter.no permalink
Harald Eilertsen (harald@quitter.no)'s status on Monday, 26-Mar-2018 06:45:38 EDT Harald Eilertsen
- Norge
Om man prøvde ville man neppe klare å parodiere dette...

http://qttr.at/22wv

Artikkelen har gode imidlertid noen poeng, men neppe noe som overrasker noen her.

http://qttr.at/22ww

!norge #aftenposten #facebook #fail

In conversation Monday, 26-Mar-2018 06:45:38 EDT from quitter.no permalink Repeated by knuthollund

Public

Notices by abjectio (knuthollund@quitter.no), page 2