This post was originally written 09/28/2015 copied from my old blog.
There seems to be at least something to the fact that the models seem harder to fit with bigger data. Our theory is that INLA crashes the model isn’t a good fit. Luckily, if you search “crash,” I’m far from the only one who has had this problem. I’m not sure yet if this is an answer, but so often in the GLMM and R world, it has something to do with an optimizer. I tried the “new” (as of April 2015) inla.control(correct=TRUE,correct.factor=10) which the authors say may become standard in a later version.
The thread I mentioned before even contains the same perplexing output I see when I run the models “verbose.” This person seems to be in a similar vein of thinking as some of my prior thoughts: he notices the models ran fine when the data set was smaller, but then the bigger set crashes. This is where I translated (maybe not correctly) the comment that follows suggesting “adding the option control.inla(diagonal=100) …also try values other than 100, such as 10 and 10000” into what they now have as a new feature (this post after all is from 2011). The author further qualifies that this option adjusts the Hessian optimization so as to make it more robust.
Further down this thread, there is a suggestion for giving INLA better starting values. That author builds on the prior suggestion by “complicating” the control.inla call like such…
control.inla = list(diagonal = 100, strategy = "gaussian", int.strategy = "eb")
This is the “cheapest” (his words) approximation, but it will do to at least point INLA in the right direction in the “real” call.
The things you could put in the option control.inla = list(strategy = “…”) when making your call to INLA can be…
 laplace – this is the “full Laplace,” and is the most intense computationally. should be used if you need e.g. higher accuracy in the tails
 simplified Laplace – default
 Gaussian – the least intense
 can be used if you’re having problems with models crashing
 the “old way”
 simplest approximation
 “cheap”
control.mode = list(result = starting.value, restart = TRUE)
…to the normal INLA call. He further suggests “cooling” the diagonal if 100 is too small, and adjusting such that you start with, e.g. 1000, then down to 100, then down to 10. In the meantime, also found a few workarounds to make the INLA crashing process less painful on Windows.
 temporal
 an idea to scale time
 alternatively code as integers (1,2,3…)
 when there aren’t random effects, glm() is a good sub
 control.inla = list(reordering = “metis”)
 INLA:::inla.dynload.
workaround()  maybe this is to use the static build for the testing version on Ubuntu?
 make a sparse matrix
 try the testing version of INLA
 restart your computer and immediately run to free up memory

 control.mode=list(theta=c( <starting values in internal scale> ), restart=TRUE)
 make sure factor names don’t include []
 better priors for fixed effects
 f(…, model=”linear”, prec.linear = 1)
 control.fixed = list(prec.intercept = 0.001)
 advice for SPDE models
 might use different functions based on size of model
 large grid problems
 graph example
 ecology examples
 consider a binary variable as a factor?
 zeroinflated binomial advice
 range of response too wide?
 when you have lots of prediction points
 CPO might use too much memory
 HPC problems
 spatial: f(ID.road, …., adjust.for.con.comp = FALSE)
 KnorrHeld Type IV