It has been occurring for the past two weeks now, at least. When
I try to load the forum (on different networks) it will often
hang for a while, and when it does eventually load a page, it is
likely that clicking a link will cause it to get stuck loading
again, or eventually display the followi
On Monday, 17 September 2018 at 11:02:39 UTC, Michael wrote:
It has been occurring for the past two weeks now, at least.
When I try to load the forum (on different networks) it will
often hang for a while, and when it does eventually load a
page, it is likely that clicking a link will cause it
On Monday, 17 September 2018 at 11:51:04 UTC, Vladimir Panteleev
wrote:
On Monday, 17 September 2018 at 11:02:39 UTC, Michael wrote:
It has been occurring for the past two weeks now, at least.
When I try to load the forum (on different networks) it will
often hang for a while, and when it does
On Monday, 17 September 2018 at 11:51:04 UTC, Vladimir Panteleev
wrote:
On Monday, 17 September 2018 at 11:02:39 UTC, Michael wrote:
It has been occurring for the past two weeks now, at least.
When I try to load the forum (on different networks) it will
often hang for a while, and when it does
On Monday, 17 September 2018 at 11:51:04 UTC, Vladimir Panteleev
wrote:
[..]
The high load is temporary, but will take a week or two to
resolve.
How feasible would be to have a simple page like
https://status.github.com/ for sharing such information?
On Monday, 17 September 2018 at 16:51:42 UTC, Petar Kirov
[ZombineDev] wrote:
On Monday, 17 September 2018 at 11:51:04 UTC, Vladimir
Panteleev wrote:
[..]
The high load is temporary, but will take a week or two to
resolve.
How feasible would be to have a simple page like
https://status.gith
On Monday, 17 September 2018 at 11:51:04 UTC, Vladimir Panteleev
wrote:
The high load is temporary, but will take a week or two to
resolve.
Performance should now be back to normal.
On Friday, 21 September 2018 at 00:57:42 UTC, Vladimir Panteleev
wrote:
On Monday, 17 September 2018 at 11:51:04 UTC, Vladimir
Panteleev wrote:
The high load is temporary, but will take a week or two to
resolve.
Performance should now be back to normal.
forum.dlang.org is temporarily down fo
On Monday, 17 September 2018 at 11:02:39 UTC, Michael wrote:
...
Yeah it happened again today. I heard this site was made in D,
maybe is because the GC?
On Tuesday, 25 September 2018 at 18:26:58 UTC, CharlesM wrote:
Yeah it happened again today. I heard this site was made in D,
maybe is because the GC?
No, just old server hardware and database fragmentation.
On Friday, 21 September 2018 at 00:57:42 UTC, Vladimir Panteleev
wrote:
Performance should now be back to normal.
Looks like my previous hunch as to why it was slow was off.
Should be fixed now.
On Tue, Sep 25, 2018 at 08:41:51PM +, Vladimir Panteleev via Digitalmars-d
wrote:
> On Tuesday, 25 September 2018 at 18:26:58 UTC, CharlesM wrote:
> > Yeah it happened again today. I heard this site was made in D, maybe
> > is because the GC?
>
> No, just old server hardware and database frag
On 9/25/18 5:05 PM, H. S. Teoh wrote:
On Tue, Sep 25, 2018 at 08:41:51PM +, Vladimir Panteleev via Digitalmars-d
wrote:
On Tuesday, 25 September 2018 at 18:26:58 UTC, CharlesM wrote:
Yeah it happened again today. I heard this site was made in D, maybe
is because the GC?
No, just old serv
On Tuesday, 25 September 2018 at 21:12:54 UTC, Steven
Schveighoffer wrote:
I'll note that when I started running into DB slowdowns on a
system (not related to D), adding one index fixed the issue.
Sometimes linear searches are fast enough to hide in plain
sight :)
I'm no DBA. Here's the schem
On Tuesday, 25 September 2018 at 21:12:54 UTC, Steven
Schveighoffer wrote:
Well, I thought it might be GC related also. It behaves
similarly to how you would expect a GC pause to behave (several
fast responses, then one that takes 5 seconds to come back).
I think that would be plausible if par
On Tuesday, 25 September 2018 at 21:20:29 UTC, Vladimir Panteleev
wrote:
Sometimes the database (SQLite) behaves unusually slow until
you tell it to analyze itself, then it figures out some
internal index it has to use that it wasn't using before (with
no changes to schema). Those analysis ru
On Tuesday, 25 September 2018 at 21:42:40 UTC, bachmeier wrote:
How much data can there possibly be for a mailing list?
Currently, 3.8 GB.
A good part of that is the full-text index required for
searching. (It does work really well, though - no need for Lucene
or such.)
I regularly see sto
On Wed, Sep 26, 2018 at 01:07:29AM +, Vladimir Panteleev via Digitalmars-d
wrote:
[...]
> One thing possible with a traditional RDBMS that's not possible with
> SQLite is processing several simultaneous requests. The synchronous
> API translates to the synchronous nature of the entire program:
On Wednesday, 26 September 2018 at 01:52:31 UTC, H. S. Teoh wrote:
I don't know what your schema looks like, so it's hard to give
specifics
https://github.com/CyberShadow/DFeed/blob/master/schema.sql
On Tuesday, 25 September 2018 at 21:20:29 UTC, Vladimir Panteleev
wrote:
Sometimes the database (SQLite)
https://github.com/CyberShadow/DFeed/blob/master/schema.sql
CREATE TABLE [Groups] (
[Group] VARCHAR(50) NULL,
[ArtNum] INTEGER NULL,
[ID] VARCHAR(50) NULL
, Time INTEGER);
If you're usi
On Wednesday, 26 September 2018 at 01:52:31 UTC, H. S. Teoh wrote:
What version of SQLite are you using? AFAIK, SQLite itself
does support concurrent access. Though it does have to be
explicitly compiled with that option, otherwise it will only
issue a runtime error. Of course, locking is no
On Wednesday, 26 September 2018 at 02:28:27 UTC, CharlesM wrote:
If you're using SQLite you don't need to specify the size of
the columns, for what I gather it's useless for this DB.
Yep, this is mostly descriptive. Types in column declarations
have mostly the same effect.
And if I'm not mis
On Wednesday, 26 September 2018 at 02:42:15 UTC, Vladimir
Panteleev wrote:
On Wednesday, 26 September 2018 at 02:28:27 UTC, CharlesM wrote:
If you're using SQLite you don't need to specify the size of
the columns, for what I gather it's useless for this DB.
Yep, this is mostly descriptive. Typ
On Tuesday, 25 September 2018 at 21:20:29 UTC, Vladimir Panteleev
wrote:
Sometimes the database (SQLite)
SQLite was designed initially to be single local process, one
connection. You should get much better results with postgres
though of course it has some maintenance overhead (mainly
inst
On Wed, Sep 26, 2018 at 02:33:27AM +, Vladimir Panteleev via Digitalmars-d
wrote:
> On Wednesday, 26 September 2018 at 01:52:31 UTC, H. S. Teoh wrote:
[...]
> > but basically, any column used in a WHERE clause is a candidate for
> > indexing.
>
> Yep, I think we're past that already.
>
> The
On Wednesday, 26 September 2018 at 02:33:27 UTC, Vladimir
Panteleev wrote:
fixed this by limiting the check to the first unread post
instead of reusing a function to count all unread messages in
the subscription queue:
https://github.com/cybershadow/DFeed/commit/9cfcab2
Seems like the issues
On Thursday, 4 October 2018 at 19:18:15 UTC, JN wrote:
Seems like the issues with the forum got worse. It's hardly
usable today, most of the time I am being greeted by "forums
are being overloaded" message.
Yeah, painfully aware. I've been trying a bunch of different
things all day, and looks
On Thu, Oct 04, 2018 at 11:51:02PM +, Vladimir Panteleev via Digitalmars-d
wrote:
> On Thursday, 4 October 2018 at 19:18:15 UTC, JN wrote:
> > Seems like the issues with the forum got worse. It's hardly usable
> > today, most of the time I am being greeted by "forums are being
> > overloaded"
On Friday, 5 October 2018 at 16:11:05 UTC, H. S. Teoh wrote:
On Thu, Oct 04, 2018 at 11:51:02PM +, Vladimir Panteleev
via Digitalmars-d wrote:
On Thursday, 4 October 2018 at 19:18:15 UTC, JN wrote:
> Seems like the issues with the forum got worse. It's hardly
> usable today, most of the tim
On Fri, Oct 05, 2018 at 07:35:11PM +, AlCaponeJr via Digitalmars-d wrote:
> On Friday, 5 October 2018 at 16:11:05 UTC, H. S. Teoh wrote:
> > On Thu, Oct 04, 2018 at 11:51:02PM +, Vladimir Panteleev via
> > Digitalmars-d wrote:
[...]
> > > Yeah, painfully aware. I've been trying a bunch of d
On 2018-10-05 22:32, H. S. Teoh wrote:
Yes, and have it go down when things like the infamous AWS Outage
happens. Centralization is evil.
And you think that cannot happen when you're managing the hardware
yourself? If you're hardware is not failing you're ISP still can. If
you're really par
On 2018-10-05 22:32, H. S. Teoh wrote:
Yes, and have it go down when things like the infamous AWS Outage
happens. Centralization is evil.
How is having single server (I assume) behind a single ISP any less
centralization than a cloud provider?
Another advantage of using the cloud is that i
On Saturday, 6 October 2018 at 09:29:42 UTC, Jacob Carlborg wrote:
Just see what has happened to the DMD nightly builds. It's been
down for weeks (soon a month?)
I've checked the logs from my stuff at Semaphore and it's since
Sept 7 to be exactly.
33 matches
Mail list logo
