Hello Mark, Thanks a lot for the comprehensive reply and valuable insights. I will try to implement. Might need to start over with the server, though. Or wait and see how it goes first.
Best regards, Andrew середа, 12 квітня 2023 р. о 15:38:42 UTC+3 Mark H. Wood пише: On Tue, Apr 11, 2023 at 08:56:07AM -0700, Andrew K wrote: > What is the optimum disk partitioning for DSpace 7? "Optimum" will be strongly dependent on (a) your OS and (b) how much you are storing in your repository. > I use a VDS, so the space is important. The aim is to have the system > partition 20-30GB and keep everything else on another partition, including > logs (they are very important AFAIK).. That seems sensible. I don't think anyone is going to have a "best way" for you, but here's what I've done. o I like to keep the Solr cores and the database each on its own volume. That way /var can fill up with log files and not stop DSpace. (These days, the DBMS is on a separate host, and I'd like to move Solr to yet another since they tend to become busy at the same time.) o I invented a configuration parameter 'dspace.var' and use it throughout the configuration, wherever DSpace is configured to store volatile files such as exported materials and the assetstore. Code and configuration are installed on the /opt volume and the rest is mounted on /var/lib/dspace. This last is again a separate volume. I've installed Monit to keep Tomcat, Solr and PostgreSQL running, monitor availability, restart anything that gets wedged, and email me if there's anything it can't handle. I also have the critical storage volumes monitored in case one comes close to filling up. I strongly recommend using a logical volume layer on top of a very simple physical partitioning scheme, so that you can add physical volumes online and portion them out as needed when logical volumes fill up. Usually I'll set up physical partitions "/" and "/boot", and make all the rest a single LVM PV partition, leaving some uncommitted storage in case I need to expand an LV more quickly than our corporate virtual-machine infrastructure can respond to my request. If I need to add physical storage, I can join it to the existing volume group, add slices to LVs as needed, and expand the LVs' filesystems into the new extents, all without interrupting service. (You don't need to understand *all* of that on Day 1, but getting the basics done at installation will make life so much nicer as the repository grows.) I need to say that usually on a new host I'll take a wild guess about how much storage will be needed for each of these various functions, then adjust when I see how the system is really operating. Some of my guesses have been quite over-generous. It's much harder to shrink a volume than to expand one, even on LVM. These days I'd probably request just as much physical storage, but leave more of it uncommitted and watch growth more closely. In the end, only a running system can tell you *precisely* what it needs to function adequately and reliably. Provide yourself with good system management tools and the ability to readily add capacity if you need it. Always give your systems a thorough inspection for capacity as annual budget time approaches. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -- All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/7af8070a-15a8-44b7-ad15-19022fb8d7a8n%40googlegroups.com.
